ZU064-05-FPR main 17 April 2014 18:21 



Under consideration for publication in J. Functional Programming 



F-ing modules 

ANDREAS ROSSBERG 
Google 
rossberg@mpi-sws.org 
and 

CLAUDIO RUSSO 
Microsoft Research 
crusso@microsoft.com 
and 

DEREK DREYER 
Max Planck Institute for Software Systems (MPI-SWS) 
dreyer@mpi-sws.org 



Abstract 

ML modules are a powerful language mechanism for decomposing programs into reusable com- 
ponents. Unfortunately, they also have a reputation for being "complex" and requiring fancy type 
theory that is mostly opaque to non-experts. While this reputation is certainly understandable, given 
the many non-standard methodologies that have been developed in the process of studying modules, 
we aim here to demonstrate that it is undeserved. To do so, we present a novel formalization of 
ML modules, which defines their semantics directly by a compositional "elaboration" translation 
into plain System F m (the higher-order polymorphic A -calculus). To demonstrate the scalability of 
our "F-ing" semantics, we use it to define a representative, higher-order ML-style module language, 
encompassing all the major features of existing ML module dialects (except for recursive modules). 
We thereby show that ML modules are merely a particular mode of use of System Fa,. 

To streamline the exposition, we present the semantics of our module language in stages. We 
begin by defining a subset of the language supporting a Standard ML-like language with second- 
class modules and generative functors. We then extend this sublanguage with the ability to package 
modules as first-class values (a very simple extension, as it turns out) and OCaml-style applicative 
functors (somewhat harder). Unlike previous work combining both generative and applicative func- 
tors, we do not require two distinct forms of functor or signature sealing. Instead, whether a functor 
is applicative or not depends only on the computational purity of its body. In fact, we argue that 
applicative/generative is rather incidental terminology for pure vs. impure functors. This approach 
results in a semantics that we feel is simpler and more natural than previous accounts, and moreover 
prohibits breaches of abstraction safety that were possible under them. 



1 Introduction 

Modularity is essential to the development and maintenance of large programs. Although 
most modern languages support modular programming and code reuse in one form or 
another, the languages in the ML family employ a particularly expressive style of mod- 
ule system. The key features shared by all the dialects of the ML module system are 
their support for hierarchical namespace management (via structures), a fine-grained va- 
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riety of interfaces (via translucent signatures), client-side data abstraction (via functors), 
implementor-side data abstraction (via sealing), and a flexible form of signature matching 
(via structural subtyping). 

Unfortunately, while the utility of ML modules is not in dispute, they have nonetheless 
acquired a reputation for being "complex". Simon Peyton Jones (2003), in an oft-cited 
POPL keynote address, likened ML modules to a Porsche, due to their "high power, but 
poor power/cost ratio". (In contrast, he likened Haskell — extended with various "sexy" 
type system extensions — to a Ford Cortina with alloy wheels.) Although we disagree with 
Peyton Jones' amusing analogy, it seems, based on conversations with many others in the 
field, that the view that ML modules are too complex for mere mortals to understand is 
sadly predominant. 

Why is this so? Are ML modules really more difficult to program, implement, or un- 
derstand than other ambitious modularity mechanisms, such as GHC's type classes with 
type equality coercions (Sulzmann et ai, 2007) or Java's classes with generics and wild- 
cards (Torgersen et ai, 2005)? We think not — although this is obviously a fundamentally 
subjective question. One can certainly engage in a constructive debate about whether the 
mechanisms that comprise the ML module system are put together in the ideal way, and in 
fact the first and third authors have recently done precisely that (Rossberg & Dreyer, 2013). 
But we do not believe that the design of the ML module system is the primary source of 
the "complexity" complaint. 

Rather, we believe the problem is that the literature on the semantics of ML-style module 
systems is so vast and fragmented that, to an outsider, it must surely be bewildering. 
Many non-standard type-theoretic (Harper et al, 1990; Harper & Lillibridge, 1994; Leroy, 
1994; Leroy, 1995; Russo, 1998; Shao, 1999; Dreyer et al, 2003), as well as several ad 
hoc, non-type-theoretic (MacQueen & Tofte, 1994; Milner et al, 1997; Biswas, 1995) 
methodologies have been developed for explaining, defining, studying, and evolving the 
ML module systems, most with subtle semantic differences that are not spelled out clearly 
and are known only to experts. As a rich type theory has developed around a number of 
these methodologies — e.g., the beautiful meta-theory of singleton kinds (Stone & Harper, 
2006) — it is perfectly understandable for someone encountering a paper on module sys- 
tems for the first time to feel intimidated by the apparent depth and breadth of knowledge 
required to understand module typechecking, let alone module compilation. 

In response to this problem, Dreyer, Crary & Harper (2003) developed a unifying type 
theory, in which previous systems could be understood as sublanguages that selectively 
include different combinations of features. Although formally and conceptually elegant, 
their unifying account — which relies on singleton kinds, dependent types, and a subtle 
effect system — still gives one the impression that ML module typechecking requires so- 
phisticated type theory. 

In this article, we take a different approach. Our goal is to show once and for all that, 
contrary to popular belief (even among experts in the field!), the semantics of ML modules 
is immediately accessible to anyone familiar with System ¥ a , the higher-order polymor- 
phic A -calculus. How do we achieve this goal? 

First, instead of defining the semantics of modules — as most prior work has done — via 
a bespoke module type system (Dreyer et al, 2003) or a non-type-theoretic formaliza- 
tion (Milner et al, 1997), we employ an elaboration semantics, in which the meaning of 
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module expressions is denned by a compositional, syntax-directed translation into plain 
System F ffl . Through this elaboration, we show that 

ML modules are merely a particular mode of use of System F m . 

A structure is just a record of existential type 3a. {I : t}, where the type variables a 
represent the abstract types defined in the structure. A functor is just a function of poly- 
morphic type Va.T — > t', parameterized over the abstract types a in its module argument. 
No dependent types of any form are required. However, as is often the case for common 
programming idioms, it is extremely helpful to have built-in language support for inference 
and automation where possible. In our "F-ing" elaboration semantics, this amounts to 
inserting the right introduction and elimination forms for universal and existential types 
in the right places, e.g., using "signature matching" to infer the appropriate type arguments 
when a functor is applied or when a structure is sealed with a signature. 

Our approach thus synthesizes elements of two alternative definitions of Standard ML 
modules given by Harper & Stone (2000) and Russo (1998). Like Harper & Stone (2000), 
we define our semantics by elaboration; but whereas Harper & Stone elaborated ML mod- 
ules into yet another (dependently-typed) module type system — a variant of Harper & Lil- 
libridge (1994) — we elaborate them into F ra , which is a significantly simpler system. Like 
Russo (1998), we classify ML modules — and interpret ML signatures — directly using the 
types of System F ffl ; but whereas Russo only presented a static semantics, our elaboration 
effectively provides an evidence translation for a simplified and streamlined variant of his 
definition, thus equipping it with a dynamic semantics and type soundness proof. 

Second, we demonstrate the broad applicability of our F-ing elaboration semantics 
by using it to define a richly-featured — and, we argue, representative — ML-style module 
language. By "representative", we mean that the language we define encompasses all 
the major features of existing ML module dialects except for recursive modules. 1 While 
other researchers have given translations from dialects of ML modules into versions of 
System F ra before (Shan, 2004; Shao, 1999), we are, to our knowledge, the first to define 
the semantics of a fully-fledged ML-style module language directly in terms of System F ra . 
By "directly", we mean that there is no other high-level static semantics involved — F<o 
types are enough to classify modules and understand their semantics. 

In contrast, most previous work on modules has focused on bespoke module calculi that 
are (a) defined independently of F m and (b) somewhat idealized, relying on a separate 
non-trivial stage of pre-elaboration to handle certain features, and often glossing over 
essential aspects of a real module language, such as shadowing between declarations, local 
or shadowed types (and the so-called avoidance problem that they induce), or composition 
constructs like open, include and where/with, all of which add — in some cases quite 
substantial — complexity. 

To ease the presentation, we present the semantics of our module language in stages. 
In the first part of the article (Sections 2-5), we show how to typecheck and implement a 
subset of our language that roughly corresponds to the Standard ML module language 

1 A proper handling of type abstraction in the presence of recursive modules seems to require both 
a more sophisticated underlying type theory (Dreyer, 2007a), as well as a more radical departure 
from the linking mechanisms of the ML module system (Rossberg & Dreyer, 2013). 
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extended with higher-order functors. This subset supports only second-class modules, 
not first-class modules (Harper & Lillibridge, 1994; Russo, 2000), and only SML-style 
generative functors, not OCaml-style applicative functors (Leroy, 1995). We start with this 
SML-style language because its F-ing semantics is relatively simple and direct. 

In the second part of the article (Sections 6-9), we extend the language of the first 
part with both modules-as-first-class-values (Section 6, easy) and applicative functors 
(Sections 7-9, harder). For the extension to applicative functors, we have taken the oppor- 
tunity to address some overly complex and/or semantically problematic aspects of previous 
approaches. In particular, unlike earlier unifying accounts of ML modules (Dreyer et ai, 
2003; Romanenko et ai, 2000; Russo, 2003), we do not require two distinct forms of 
functor declaration (or two different forms of module sealing). Instead, our type system 
deems a functor to be applicative iff the body of the functor is computationally pure, 
and generative otherwise. We believe this is about as simple a characterization of the 
applicative/generative distinction as one could hope for. 

That said, the semantics we give for applicative functors is definitely not as simple as 
the elaboration semantics for generative functors given in the first part of the article. We 
believe the relative complexity of our applicative functor semantics is not a weakness of 
our approach, but rather a reflection of the inescapable fact that the applicative semantics 
for functors is inherently subtler (and harder to get right!) than the generative semantics. 
We substantiate this claim by showing that no previous account of applicative functors has 
properly guaranteed abstraction safety — i.e., the ability to locally establish representation 
invariants for abstract types. 2 To avoid this problem, we revive the long-lost notion of 
structure sharing from Standard ML '90 (Milner et al, 1990), in the form of more fine- 
grained value sharing. Although previous work on module type systems has disparaged this 
form of sharing as type-theoretically questionable, we observe that it is in fact necessary 
in order to ensure abstraction safety in the presence of applicative functors. Furthermore, 
it is easy to account for in a type-theoretic manner using "phantom types" as "stamps". 

In general, we have tried to give this article the flavor of a brisk tutorial, assuming 
of the reader no prior knowledge concerning the typechecking and implementation of 
ML modules. However, this is not (intended to be) a tutorial on programming with ML 
modules, nor is it a tutorial on the design considerations that influenced the development of 
ML modules. For the former, there are numerous sources to choose from, such as Harper's 
draft book on SML (Harper, 2012) and Paulson's book (1996). For the latter, we refer the 
reader to Harper & Pierce (2005), as well as the early chapters of the second and third 
authors' PhD theses (Russo, 1998; Dreyer, 2005). 



2 As further evidence of the relative complexity of applicative functors, we note that the F-ing 
semantics for applicative functors fundamentally requires Fa/s higher kinds, while the generative 
functor semantics presented in the first part of the article does not. Higher kinds are of course 
needed if the underlying core language (on top of which the module system is built) supports type 
constructors — as is the case in ML. However, setting the core language aside, the elaboration 
semantics we give in the first part of the article does not itself rely on higher-kinded type 
abstraction, and indeed, for a simpler core language with just type (but not type constructor) 
definitions, that language can be elaborated to plain System F. By contrast, the applicative functor 
extension presented in the second part of the article relies on higher kinds in an essential way. 
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The F-ing approach has of course not fallen from the sky. It naturally builds on many 
ideas from previous work. As mentioned above, the central insight of viewing the seem- 
ingly dependent type system of ML modules through the lens of System F types is due 
to Russo (1998; 1999), and many of the ideas for translating module terms are already 
present in prior work by Harper et al. (1990), Harper & Stone (2000), and Dreyer (2007b). 
Our technical development of applicative functors is directly influenced by the work of 
Biswas (1995), Russo (1998; 2003), and Shan (2004), and more indirectly by Shao (1999) 
and Dreyer et al. (2003). But instead of frontloading this article with a survey of the 
literature, we will point to the origins of some key ideas as we come to them. A more 
comprehensive discussion can be found in Section 11. 

To summarize our contributions, we present the first formalization of ML modules that 

(1) explains the static and dynamic semantics of a fully-fledged module system, 
directly in terms of System F ffl terms, types and environments, 
requiring only plain ¥ a to do so, and 

(2) characterizes applicativity/generativity of functors as a matter of purity, 
and supports applicative functors in a way that is abstraction-safe, 

by relying crucially on a novel account of value sharing. 

For those familiar with an earlier version of this article that was published in the TLDI 
workshop (Rossberg et al, 2010), we note that the major difference in the present version 
is contribution #2, that is, the novel account of applicative functors in Sections 7-9 (the 
workshop version only treated generative functors). We now also offer expanded discus- 
sions of first-class modules (Section 6), our Coq mechanization (Section 10), and related 
work (Section 11), as well as more details of the meta-theory (Section 5). 

2 The module language 

Figure 1 presents the syntax of our module language. We assume a core language con- 
sisting of syntax for kinds, types, and expressions, whose details do not matter for our 
development. Binding constructs for types and values are provided as part of the module 
language. For simplicity, we assume that all language entities share a single identifier 
syntax. 3 

The module language is very similar to that of Standard ML, except that functors are 
higher-order, and signature declarations may be nested inside structures. The syntax con- 
tains all the features one would expect to find: bindings and declarations of values, types, 
modules, and signatures (where, as in SML, we implicitly allow omitting the separating ";" 
between the bindings/declarations in a sequence); hierarchical structures with projection 
via the dot notation; structure/signature inheritance with include; functors and functor 
signatures; and sealing (a.k.a. opaque signature ascription). In the grammar for the "where 
type" construct we abuse the notation X to denote an identifier followed by a (possibly 
empty) sequence of projections, e.g., X oxX.Y.Z. 

3 For an ML-like core language, this is meant to include type variables 'a, and we do not impose any 
restrictions on where type variables from the context can appear in type and signature expressions. 
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(identifiers) 


X 


(kinds) 


K ::= ... 


(types) 


T ::= ... | P 


(expressions) 


E ::= ... j P 


(paths) 


P ::= M 



(modules) M 



(bindings) B 



(types) 

(expressions) 

(signatures) 

(modules) 



(declarations) 
(bindings) 



X 

{B} | M.X 
fun X:S^>M 
X:>S 

va\X=E 
typeX=T 
module X=M 
signature X=S 
include M 

£ 

B;B 



XX 



(signatures) 



(declarations) D 



Fig. 1 . Syntax of the module language 



let B in T 
let B in E 
let B in 5 

PM 

let B in M 

Mi M2 
M:>S 
M:S 

local B in D 
signature X(X':S')=S 
local B in B' 
signature X(X':S')=S 



{D} 

(X:S)^S 

5 where typeX=r 
va\X:T 

typeX=T I typeX:A: 
module X:S 
signature X=S 
include S 

e 

D;D 



{B; typeX=T}.X 
{B; val X=E}.X 
{B; signature X=S}.X 
(PM).S 

{B; module X=M}.X 

let module X\=M\ \ module Xi_=M2 in X\Xi 

let module X=M in X:>S 

(fun X:S^X)M 

include (let B in {»}) 

module X : (X':S') -y {signature S=5} 

include (let B in {£'}) 

moduleX = funX':5'=>{signature S=5} 



Fig. 2. Derived forms 



In some cases, the syntax restricts module expressions in certain positions (e.g., the com- 
ponents of a functor application) to be identifiers X. This is merely to make the semantics 
of the language that we define in Section 4 as simple as possible. 

Fully general variants of these constructs are definable as straightforward derived forms, 
as shown in Figure 2. The same figure also defines other constructs that are available in 
various dialects of ML modules, such as "let"-expressions on all syntactic levels (including 
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types and signatures), "local" bindings/declarations 4 , and parameterized signatures. 5 Using 
some of these derived forms, Figure 3 shows the implementation of a standard Set functor. 

One point of note is the notion of paths. A path P is the mechanism by which types, 
values, and signatures may be projected out of modules. In SML and OCaml, paths are 
syntactically restricted module expressions, such as an identifier X followed by a series of 
projections. The reason for the syntactic restriction is essentially that not all projections 
from modules are sensible. For example, consider a module (M :> {type t; val v:t}) that 
defines both an abstract type t and a value v of type t. Then (M :> {type t; val v:t}).t is 
not a valid path, because it denotes a fresh abstract type that is not well defined outside of 
the module. Put another way, projecting t does not make sense because the sealing in the 
definition of the module should prevent one from tying the identity of its t component back 
to the module expression itself. Likewise, (M :> {type t; val v:t}).v is not valid because 
it cannot be given a type that makes sense outside of the module. (We will explain the issue 
with paths in more detail in Section 4.) 

Here, instead of restricting the syntax of paths P, we instead restrict their semantics. That 
is, paths are syntactically just arbitrary module expressions, but with a separate typing rule. 
This rule will impose additional restrictions on P's signature, to make sure that no locally 
defined abstract types escape their scope. 

In a similar manner, our module-level projection construct MX is also more permissive 
than in actual SML, in that M is allowed to be an arbitrary module expression. It is worth 
noting that this, together with our more permissive notion of path, allows us to define very 
general forms of local module bindings simply as derived syntax (Figure 2). 



3 System ¥ m 

Our goal in this article is to define the semantics of the module language by translation 
into System F ffl . To differentiate external (module) and internal (F ffl ) language, we use 
lowercase letters to range over phrases of the latter. Figure 4 gives the syntax of the variant 
of System F<b that we use as the target of our elaboration. It includes record types (where 
we assume that labels are always disjoint), but is otherwise completely standard. 

We note in passing that we are using the usual impredicative definition of F^, in this 
article. Up to the introduction of first-class modules in Section 6 we could actually restrict 
ourselves to a predicative variant. Likewise, as mentioned earlier, up to the introduction of 
applicative functors in Section 7, the elaboration does not actually require higher kinds (un- 
less used by the Core language); second-order System F would suffice. But for simplicity, 
we have chosen to use just one version of the target language throughout the article. 



The module-level include M is spelled open M in Standard ML. OCaml's version of open M can 
be expressed as local include M in ... in our system. 
5 Parameterized signatures may be less familiar to many readers, given that only a few ML dialects 
support them. A signature declared via signature A (X : B) = . . . takes a module parameter, and 
is instantiated with an application A M in a signature expression. Such a parameterized signature 
definition simply desugars to a functor definition wherein the result contains a single (ordinary) 
signature component under the fixed (but otherwise arbitrary) name S. 
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signature EQ = 

{ 

type t 

val eq : t x t — > bool 

} 

signature ORD = 

{ 

include EQ 

val less :txt-t bool 

} 

signature SET = 

{ 

type set 

type elem 

val empty : set 

val add : elem x set — > set 

val mem : elem x set — > bool 

} 

module Set = fun Elem : ORD => 

{ 

type elem = Elem.t 
type set = list elem 
val empty = [] 
val add (x, s) = case s of 

I [] =* M 

| y :: s' => if Elem.eq (x, y) then s else if Elem. less (x, y) then x :: s else y :: add (x, s') 
val mem (x, s) = case s of 
| [] => false 

| y::s' => Elem.eq (y, x) or (Elem. less (y, x) and mem (x, s')) 
} :> SET where type elem = Elem.t 

module IntSet = Set {type t = int; val eq = Int.eq; val less = Int. less} 

Fig. 3. Example: a functor for sets 



(kinds) K ::= £1 \ K — } K 

(types) t ::= a | t | {/:t} | Va:ff.T | 3a:K.x | Xa:K.T | t t 

(terms) e ::= x \ Xx:T.e \e e \ {l=e} \ e.l \ Xa:K.e \ e T | pack (T,e) T | unpack (a,x)=e in e 
(values) v ::= Xx:r.e \ {l=v} \ Xa:K.e \ pack (t,v) t 
(environ's) r ::= • | r,a:ic| T,x:x 

Fig. 4. Syntax of F m 



In the grammar, and elsewhere, we liberally use the meta-notation A to stand for zero or 
more iterations of an object or formula A. (We will also sometimes abuse the notation A to 
actually denote the unordered set {A}.) 

We write fv(r) for the free variables of 1. 



ZU064-05-FPR main 17 April 2014 18:21 



F-ing modules 9 

Semantics The full static semantics is given in Figure 5. Type equivalence is denned as 
j3 7] -equivalence. The only other point of note is that, unlike in most presentations, our 
typing environments T permit shadowing of bindings for value variables x (but not for type 
variables a). Thus, we take the notation F(x) to denote the rightmost binding of x in T. 
Allowing shadowing turns out to be convenient for our purposes (see Section 4). 

We assume a standard left-to-right call-by-value dynamic semantics, which is defined in 
Figure 6. However, other choices of evaluation order are possible as well, and would not 
affect our development. 

Properties The calculus as defined here enjoys the standard soundness properties: 

Theorem 3.1 {Preservation) 

If • h e : X and e <-> e', then ■ h e' : X. 

Theorem 3.2 (Progress) 

If • h e : X and e ^ v for any v, then e e 1 for some e' . 

The proofs are entirely standard, and thus omitted. 

The calculus also has the usual technical properties, the most relevant for our purposes 
being the following: 

Lemma 3.3 (Validity) 

1. Ifrhr:£2, thenThD. 

2. If Their, thenThT:il 

Lemma 3.4 (Weakening) 

Let r' d r with r' h □. 

1. IfThr: k, thenT'hr: K. 

2. If The: r, then T' h e : T. 

Lemma 3.5 (Strengthening) 

Let r'CT with T' h □ and D = dom(r) \ dom(r'). 

1. If r h T : K and fv(r) f)D = 0, then r' h T : K. 

2. If T h e : x and fv(e) flZ) = 0, then T' h e : T. 

Theorem 3.6 (Uniqueness of types and kinds) 
Assume T h □. 

1. If T h x : Jfi and T h T : K"2, then Kj = )C2. 

2. If T h e : X\ and r h e : X2, then Ti = T2. 

Finally, all judgments of the F ro type system are decidable: 

Theorem 3.7 (Decidability) 

1. It is decidable whether T h □. 

2. It is decidable whether F\- x : K. 

3. It is decidable whether F\- e : x. 

4. If r h Ti : K and r h T2 : K", it is decidable whether Ti = T2. 
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Environments 



T\-U 



a g dom(r) 



•hD 



r,a-.K\-a 



n-x:n 

r,x:z\-D 



rh-n 



Types 



r h n : £2 r h t 2 : £2 Fh f.Q. r h □ 



r I- T] -> T 2 : £2 

r\-a r,a-.K\- x-.q 

rh a :T(a) rh Va:K\T:£2 



r,a:ffh t : k' 



T h n : )f' 



rh{/:T}:£2 

r,a:icl- t : £2 
rh 3a:K.T : £2 

r h t 2 : k:' 



T h Ti T 2 : K 



Thr: K 



Terms 



ThD rhe:l' t' = t rhT:£2 

r h x : rhe:T 

r,rlhe:l' r h e x T rhe 2 :l' 



rh Xx:x.e : T — > t' 



rhe:l ThD r h e : {/:t,Z':t'} 
f h {7=4 : {tx} rhelTr 

r,a:iche:T rhe:Va:K\T' rh-r:ic 

Th la:ff.e : Vo::k:.t r h e t : t'[t/oc] 

rhT:(f rhe:i'[T/a] r h 3a:K.t' : £2 
Th pack (T,e)g„ :K . T / : 3a:K.x' 

rhei : 30£:k\t' r.ai^ri'l-Q:! rhT:£2 
r h unpack (a,x}=ei in e 2 : T 



Their 



7>/?e equivalence 



X = T T = T 

= <r' 



T = T T = r 

T, = Tj T 2 = T 2 



T= T 



t= r 



Tl -Tz = Tj -> T 2 = {Z:t'} 

T = T' T = t' 



Va:fCT = Va:ic.-r' 3a:ic.T = 3a:ic.-r' 
t = t' Ti = tJ t 2 = t 2 



Iccic.t = la-.K.t' 



1 L 2 

a ^ fv(T) 



(Aa:)f.Ti) t 2 = Ti[-r 2 /a] (Aa:K.T a) = t 
Fig. 5. Fto typing 
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Reduction 



e <-)■ e' 



(Xx:x.e) v ^ e[v/x] 



{/l=Vl,/=V,/2=V 2 }./ ^ v 

(Xa:K.e) x ^4 e[r/a] 

unpack (a,*) = pack (t,v) t / in e ^ e[r/a][v/x] 

C[e] -4 C[e'] 



if e ^ e' 



C::= [] | Ce \ vC\ {l l= v,l=C,h=e} \ C.l\Cz \ pack<T,C) T | unpack (a,x)=Cme 

Fig. 6. Fa, reduction 

Note that Ti = T2 is defined over raw (i.e., not necessarily well-kinded) types; in particular, 
even if Ti and T2 are well-kinded, their equivalence may be established by transitively 
connecting them through some intermediate types that are ill-kinded. However, as long as 
Ti and T2 are well-kinded, and they have the same kind, one can test for their equality 
by j3 77 -reducing them to normal forms (a process which must terminate due to strong 
normalization of j3 77 -reduction) and then comparing the normal forms for a -equivalence. 
The proof that this algorithm is complete requires only a straightforward extension of the 
corresponding proof for the simply-typed A -calculus (Geuvers, 1992), of which F ffl 's type 
language is but a minor generalization. 

From here on, we will usually silently assume all these standard properties as given and 
omit any explicit reference to the above lemmas and theorems. 

Parallel substitution We will also make use of parallel type substitutions on F m types 
and terms. We write them as [t/o] and implicitly assume that T and a are vectors with 
the same arity. Furthermore, the following definitions and lemmas will come in handy in 
dealing with parallel type substitutions in proofs. 

Definition 3.8 (Typing of type substitutions) 
We write T' h [x/a] : T if and only if 

1. r'hn, 

2. aCdom(r), 

3. for all a € dom(r), V h a\x/a] : T(a), 

4. for all x e dom(r), r'hx: F(x)[l/a}. 

Lemma 3.9 (Type substitution) 
Let T' h [f/a] : T. Then: 

1. If r h t' : k, then V h T'[r/a] : k. 

2. If T h e : t', then T' h e[t/a] : t'[t/«]. 

Abbreviations Figure 7 defines some syntactic sugar for n-ary pack's and unpack's that 
introduce/eliminate existential types 3a. T quantifying over several type variables at once. 
We will use n-ary forms of other constructs (e.g., application of a type X), defined in all 
instances in the obvious way. 

To ease notation in the elaboration rules that follow, we will typically omit kind anno- 
tations on type variables in the environment and on binders. Where needed, we use the 
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3e.T 
3a. t 

pack (e,e) 3£ To 
pack (T,e) 3a . To 
unpack (e,x:x) = e\ in £2 
unpack {a,x:x) = e\ in e2 



= T 



= 3a\3a! .% 



— e 



= pack (repack (T',e> 3 ^. Tb[Tl/ai] }3«. Ti) 



= let x:t = ei in e2 

— unpack {a\,x\) = ei in unpack (a' ,x:x) = x\ in 

— (Xx?c.e2)e\ 



\etx\T = e\ in e2 



(where t = X\ T? and a = a\ a') 



Fig. 7. Notational abbreviations for F, 



ft) 



notation K a to refer to the kind implicitly associated with a. For brevity, we will also 
usually drop the type annotations from let, pack, and unpack when they are clear from 
context. 



We will now define the semantics of the module language by elaboration into System 
F a . That is, we will give (syntax-directed) translation rules that interpret signatures as 
types, and modules as Fo terms. Our elaboration translation builds on a number of ideas 
for representing modules that originate in previous work (see Section 11 for a detailed 
discussion), but we do not assume that the reader is familiar with any of these ideas and 
thus explain them all from first principles. 

Identifiers In order to treat identifier bindings in as simple a manner as possible, we make 
several assumptions. First, we assume that identifiers X of the module language can be 
injectively mapped to variables x of F^,. To streamline the presentation, we assume that 
this mapping is applied implicitly, and thus we use module-language identifiers as if they 
were F m variables. 

Second, we assume that there is an injective embedding of F ffl variables into F a labels. 
That is, for every (free) variable x there is a unique label l x from which x can be recon- 
structed. Together with the first assumption this means that, wherever we write lx (with X 
being a module language identifier), we take this to mean that X has been embedded into 
the set of F ffl variables, which in turn has been embedded into the set of labels. Since both 
embeddings are injective, X uniquely determines lx and vice versa. 

For simplicity, we assume here that all entities of the language share a single identifier 
namespace. Obviously, this could be refined by using different injection functions for the 
different namespaces, with disjoint images. 

Finally, we deal with shadowing of module-language identifiers simply via shadowing in 
the F ra environment (see Section 3). Consequently, we need not make any specific provision 
for variable shadowing in our rules. Only when identifiers are turned into labels (e.g., as 
structure fields) do we need to explicitly avoid duplicates. 



4 Elaboration 



Judgments The judgments comprising our elaboration semantics are listed in Figure 8. 
Most of these are translation judgments, one for each syntactic class of the module lan- 
guage, which translate module-language entities into F a entities of the corresponding 
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(kind elaboration) 
(type elaboration) 
(expression elaboration) 

(path elaboration) 
(module elaboration) 
(binding elaboration) 

(signature elaboration) 
(declaration elaboration) 

(signature subtyping) 
(signature matching) 



T\-K^K 
rh T : K~* T 

ri-B:S-»c 

ri-s^s 
ri-z)-s 

r h s < s' ~* f 
ri-£<s'tT~>/ 



such that rh T : fc 
such that r h e : T 

such that r h e : £ 
such that T h e : S 
such that r h e : S 

such that r h E : SI 
such that r h E : SI 

such that T h / : E - 
such that r h / : £ - 
(where E' : 



£'[r/a] 
= 3a.£') 



Fig. 8. Elaboration judgments 



(abstract signatures) E 
(concrete signatures) £ 



3a.E 

[t] | [=t:k] I [=E] | {I^TE} I Va.E^E 



(meta-projection) E.e 



{/:£,/':£'}././ 
Fig. 9. Semantic signatures 



E 

E.7 



variety. (Strictly speaking, we ambiguously overload the same notation for module and 
path judgments, since P syntactically expands to M. But it will always be clear from 
context which judgment is referenced.) The last two are auxiliary judgments for signature 
subtyping and matching, which we will explain a bit later. 

For each judgment, the figure also shows the corresponding elaboration invariant. We 
will prove that these invariants hold (and that the translation thereby is sound) later, in 
Section 5.1. To prove them, we assume that elaboration starts out with a well-formed 
context r. In fact, elaboration will maintain much stronger invariants for Y, which are 
important in the proof of decidability of typechecking, but we leave discussion of the 
details until later (see the "Module elaboration" section below, as well as Section 5.2). 

In places where we do not care about evidence terms, we will often write judgments 
without the e" or /" part. In addition, we use T h E <> S' as a shorthand for 
mutual subtyping T h E < S' A T h S' < E. 

A number of the elaboration judgments concern semantic signatures T. or E. Semantic 
signatures are just a subclass of F ra types that serve as the semantic interpretations of 
syntactic (i.e., module-language) signatures S, as well as the classifiers of modules M. 
Since semantic signatures are so central to elaboration, we'll start by explaining how they 
work. 



Semantic signatures The syntax of semantic signatures is given in Figure 9. (And no, 
this is not an oxymoron, for in our setting the "semantic objects" we are using to model 
modules are merely pieces of F^ syntax.) 

Following Mitchell & Plotkin (1988), the basic idea behind semantic signatures is to 
view a signature as an existential type, with the existential serving as a binder for all the 
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abstract types declared in the signature. In particular, an abstract semantic signature E has 
the form 3a. E, where a names all the abstract types declared in the signature, and where 
E is a concrete version of the signature. E is concrete in the sense that each (formerly) 
abstract type declaration is made transparently equal to the corresponding existentially- 
bound variable among the a. (We will see an example of this below.) The splitting of an 
abstract signature 3a.E into these two components — the abstract types a and the concrete 
signature E — plays a key role in the elaboration of module binding (as we explain in the 
"Module elaboration" section below). 

A concrete signature E, in turn, can be either an atomic signature ([t], [= T : k], or 
[= E], each denoting a single anonymous value, type, or signature declaration, respec- 
tively), a structure signature (represented as a record type {lx : E}), or a functor signature 
(represented by the polymorphic function type Va.E — ► E). 

Instead of adding atomic signatures as primitive constructs to the type system of the 
internal language (like in previous work, e.g., Dreyer et al. (2003)), we simply encode 
them as syntactic sugar for F^, types of a certain form. Their encodings are shown in 
Figure 10, along with corresponding term forms (which we will use in the translation of 
modules), and associated typing rules that are admissible in System F ffl . The encodings 
refer to special labels val, typ, and sig, which we assume are disjoint from the set of labels 
lx corresponding to module-language identifiers. Of particular note are the encodings for 
type and signature declarations, which may seem slightly odd because they both appear 
to declare a value of the same type as the identity function. This is merely a coding trick: 
type and signature declarations are only relevant at compile time, and thus the actual values 
that inhabit these atomic signatures are irrelevant. The important point is that (1) they are 
inhabited, and (2) the signatures [= T : k\ and [= E] are injective, i.e., uniquely (up to F m 
type equivalence) determine % and E, respectively. The encoding for [= T : k] is chosen 
such that it supports arbitrary K. Beyond these properties the "implementation details" of 
the encodings are immaterial to the rest of our development, and the reader should simply 
view them as abstractions. 

In the remainder of this article, we will assume implicitly that all semantic types and sig- 
natures are reduced to j3 77 -normal form. Likewise, we assume that all uses of substitution 
are followed by an implicit normalization step. This is convenient as a way of determinizing 
elaboration, as well as ensuring that types produced by elaboration mention the minimal 
set of free type variables relevant to their identity (cf. "path elaboration" below). 



Signature elaboration The elaboration of signatures (Figure 1 1) is not difficult. The only 
significant difference between a syntactic module-language signature and its semantic in- 
terpretation is that, in the latter, all the abstract types declared in the signature are collected 
together, hoisted out (notably, in rule D-MOD), and bound existentially at the outermost 
level of the signature. 

For example, consider the following syntactic signature: 



{module A : {type t; val v : t}; 
signature S = {val f : A.t -> int}} 
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(types) [t 
[= 
[= 


% : 




= {val : t} 
= {typ :Va : 
= {sig:S^S} 


S1).«t-> cut} 








(terms) [e] 
[* 

[s 






= {val = e} 

= {typ = Aa:(ic- 

= {sig = Ax : S.x} 


-* i2).A* : a-r.x} 








Types rh t: 


n 




rh t: k 


rhH:n 


rhr 


K 


rh[x] 


n 


r h [= t : k] : a r h [= S] : n 








Teriras r h e : t 






rh t: ff 


rh£:£2 


The 


T 


rh[e]:[T 




r h [t : xr] : [= t : v] 


rh[S]:[=S] 








7>/?e equivalence 




T = 


t' S = 






T = 


T' 



[= s] = [=s'] 

Fig. 10. F m encodings of atomic signatures and admissible typing rules 



This signature declares one abstract type (A.t), so the semantic F m interpretation of the 
signature will bind one abstract type a: 

3a. { l A : {/ t : [= a : Q], Z v : [a]}, J s : [= {/ f : [a int]}] } 

For legibility, in the sequel we'll finesse the injections (lx) from source identifiers into 
labels, instead writing this signature as: 

3o.{A:{t:[=o:n], v: [a]}, S : [= {f: [o^int]}] } 

The signature is modeled as a record type with two fields, A and S. The A field has two 
subfields — t and v — the first of which has an atomic signature denoting that t is a type 
component equal to a, the second of which has an atomic signature denoting that v is a 
value component of type a (i.e., t). The S field has an atomic signature denoting that S is 
a signature component whose definition is the semantic signature {f : [a — >• int]}. 

Note that, by hoisting the binding for the abstract type a to the outermost scope of the 
signature, we have made the apparent dependency between the declaration of signature S 
and the declaration of module A — i.e., the reference in S's declaration to the type A.t — 
disappear! Moreover, whereas in the original syntactic signature the abstract type was 
referred to as t in one place and as A.t in another, in the semantic signature all references 
to the same abstract type component use the same name (here, a). These simplifications 

(1) make clear that you do not need dependent types in order to model ML signatures, and 

(2) allow us to avoid any "signature strengthening" (aka "selfificaiion") machinery, of the 
sort one finds in all the "syntactic" type systems for modules (Harper & Lillibridge, 1994; 
Leroy, 1994; Leroy, 1995; Shao, 1999; Dreyer et al, 2003). 

The only semantic signature form not exhibited in the above example is the functor 
signature Va.E — > S. The important point about this signature is that the a are universally 
quantified, which enables them to be mentioned in both the argument signature E and the 
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r h P : [= E] ~> e 
fKP^Ts 



S-PATH 



„ . '- S -STRUCT 

rh {D} ~» s 
ri-5i^3ce.Z r,a,X:£hS 2 ~»2 



S-FUNCT 



rh (X:5i)^5 2 ^Va.E^S 

rh 3aiaa 2 .L E./x = [=a:k\ F\-T:k-^t 
T h 5 where type X=T ^ 35! a 2 .£[-r/a] 



rhs^s 



S-WHERE-TYP 



Declarations 



rhz)-*s 



rh r : n~» t 



rhvalX:r^{/ x :[T]} 



D-VAL 



rh r : k~» t 



D-TYP-EQ 



T h K ~> K a 



rhtypeX=r^{/ x :[=T:fc]} r h type X:K ~» 3a.{l x : [= a : K a ]} 

r h S ~» 35.E 

D-MOD 



D-TYP 



T h module X:S ~* 3a.{l x : S} 

rhs^s 

r h signature X=S ^ {l x : [= S]} 



D-SIG-EQ 



r h 5 ^ 35.{/ x : £} 



D-INCL 



The^{} 



D-EMT 



T h include 5 ~» 3a. {/ x : £} 

_j;hZ)i^3ai.{/x7T£i} 
r, ai ,X, h » 2 - 3a 2 .{/ X2 : Z 2 } Z Xl n / Xz = 0 

— — — D-SEQ 

r h D] ;D 2 ^ 3ct! a 2 .{Z Xl : Ej , fr 2 : Z 2 } 

Fig. 11. Signature elaboration 



result signature E. If functor signatures were instead represented as S — > S , then the result 
signature S' would not be able to depend on any abstract types declared in the argument. 

An example of a functor signature can be seen in Figure 12. It gives the translation of 
the signature SET from the example in Figure 3, along with the translation of the signature 

(Elem : ORD) -> (SET where type elem = Elem.t) 

which classifies the Set functor itself. 

Given our informal explanation, the formal rules in Figure 1 1 should now be very easy 
to follow. A few points of note, though. 

The rule S-WHERE-TYP for where type employs a convenient bit of shorthand notation 
defined in Figure 9, namely: L./ x denotes the signature of the lx component of E. This is 
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SET ~» 3aioi2-{set : [= oci : A], 



elem : [= «2 : ft], 
empty: [oti], 
add : [02 xa^ oti], 
mem : [ct2 xai-> bool]} 



(Elem : ORD) — ► (SET where type elem = Elem.t) 

~* Va.{t : [= a : ft], 

eq : [a x a — > bool], 
less : [a x a -» bool]} 
->-3j8.{set: [=J3 :ft], 

elem : [= a : ft], 

empty: [j3], 

add : [a xj3 ->•£], 

mem : [a x j3 -> bool]} 

Fig. 12. Example: signature elaboration 



used to check that the type component being refined is in fact an abstract type component 
(i.e., equivalent to one of the a bound existentially by the signature). 

In the rule D-SEQ, for sequences of declarations D\ \Di, the side condition that the label 
sets lx l and lx 2 are disjoint is imposed because signatures may not declare two components 
with the same name. Also, note that the identifiers X\ , implicitly embedded as F ffl variables, 
may shadow other bindings in F. This is one place where it is convenient to rely on 
shadowing being permissible in the F ffl environments. 

Finally, the rule S-PATH for signature paths P refers in its premise to the path elaboration 
judgment (which we will discuss later, see Figure 17) solely in order to look up the 
semantic signature E that P should expand to. As noted above in the discussion of atomic 
signatures, the actual term e inhabiting the atomic signature [= E] is irrelevant. 

Signature matching and subtyping Signature matching (Figure 13) is a key element of 
the ML module system. For sealed module expressions, we must check that the signature 
of the module being sealed matches the sealing signature. At functor applications, we must 
check that the signature of the actual argument matches the formal argument signature of 
the functor. 

What happens during signature matching is really quite simple. First of all, in all places 
where signature matching occurs, the source signature — i.e., the signature of the module 
being matched — is expressible as a concrete semantic signature E. (To see why, skip ahead 
to module elaboration.) The target signature — i.e., the signature being matched against — 
on the other hand is abstract. To match against an abstract signature 3a. E', we must solve 
for the a. That is, we must find some T such that the source signature matches E'[r/a]. 
(Fortunately, if such a t exists, it is unique, and there is an easy way of finding it by 
inspecting E — the details are in Section 5.2.) Then, the problem of signature matching 
reduces to the question of whether E is a subtype of E'[r/a], which can be determined by 
a straightforward structural analysis of the two concrete signatures. 

As a simple example, consider matching 



{A: {t: [=int:£2], u : [int], v: [int]}, S: 



[={f: [intent]}]} 
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Matching rhE^St 7 ^/ 



r\-T-.Ka ri-i<r'[f/a]-»/ 

FhI<3^W U-MATCH 



Subtyping 



rhs<s'-*/ 



r h t < t' ~* f 

rh[l]< \f\ Xx:[T].[f(x.\/a\)] 



U-VAL 



t = r 

r I- [= t : k] < [= t' : jc] ~> Ax:[= t : k].x 



U-TYP 



ri-s<s'-»/ ri-s'<3-»/' 
rh[=si<h s'l — Ajc:r=Ei.rs'i " SIG 



rh{/i :Zuh:Ta}<{h ~* br.{h :Z u h:Ta}-{h = /(*-*i)} 

r, a' I- £' < 3a.Z f t ~» h r, a' h- E[r/a] <5.'~*f 2 
T h (Va.L — > E) < (Va'.Z' -> E') ~» A/:(Va.Z -> E). A a'. Ax:Z'. / 2 (/t (f x x)) 

r,ahZ<3a'.Z'tt^/ 



U-STRUCT 



U-FUNCT 



T h 3a. £ < 3a' X' ~» Ax:(3a.L). unpack (a,y) =x in pack {z,fy) 
Fig. 13. Signature matching and subtyping 



U-ABS 



against the abstract signature 

3o.{A:{t:[=a:£l], v: [a]}, S : [= {f: [a->int]}]} 

from our signature elaboration example (above). The T returned by the matching judgment 
would here be simply int, and the subtyping check would determine that the first signature 
is a structural (width and depth) subtype of the second after substituting int for a. 

The signature matching judgment has the form rhE<S|f^> /.It matches a concrete 
E against an abstract E of the form 3a. E' as described above, non-deterministically synthe- 
sizing the solution f for a, as well as the coercion / from E to E'[f/a] (rule U-MATCH). 

While the purpose of signature matching is to relate concrete to abstract signatures, 
signature subtyping, T h S < E' ~» /, only relates signatures within the same class and 
synthesizes a respective coercion. Consequently, subtyping is defined by cases on E and 

For value declarations (rule U-VAL), signature subtyping appeals to an assumed subtyp- 
ing judgment for the core language, T h T < t' ~» /. For a core language with no subtyping 
the premise would degenerate to "t = t"\ For an ML-like core language, subtyping serves 
to specialize a more general polymorphic type scheme to a less general one. To take a 
concrete example, the empty field of the Set functor in Figure 3 would, in ML, receive 
polymorphic scheme Vj3.listj3, but when the functor body is matched against the sealing 
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signature (SET where type . . . ), the type of empty would be coerced to the monomorphic 
type list a (where a represents Elem.t). 

For type declarations (rule U-TYP), we require type equivalence, so subtyping just 
produces an identity coercion. 

For signature declarations (rule U-SIG), we do not require that they are equal (as types), 
but merely mutual subtypes, because type equivalence would be too fine-grained. In partic- 
ular, signatures that differ syntactically only in the order of their declarations will elaborate 
to semantic signatures that differ only in the order in which their existential type variables 
are bound. Such differences should be inconsequential in the source program. And indeed, 
the order of quantifiers does not matter anywhere in our rules, because they are only used 
for matching, and pushed around en bloc in all other places. (Ordering of quantifiers 
will, however, matter for modules as first-class values — see the discussion of signature 
normalization in Section 6.) 

For structure signatures, we allow both width and depth subtyping (rule U-STRUCT). For 
functor signatures, Va.E — > E and Va'.E' — > E', subtyping proceeds in the usual contra- and 
co- variant manner (rule U-FUNCT): after introducing a', we match the domains contravari- 
antly to determine an instantiation x for a such that E' < E[r/a]; then, we (covariantly) 
check that the (instantiated) co-domain E[t/(x] subtypes E'. This allows for polymorphic 
specialization, i.e., a more polymorphic functor signature may subtype a less polymorphic 
one. 

Dually, for abstract semantic signatures 3a. E and 3a' . E', subtyping recursively reduces 
to eliminating 3a.E, then matching E against E' to determine witness types T for a'; thus, 
a less abstract signature may subtype a more abstract one (rule U-ABS). 

The coercion terms / synthesized by the subtyping rules are straightforward — given the 
required invariant, T h / : E — > E', they practically write themselves. This invariant also 
determines the elided type annotation on the pack expression in the U-ABS rule. 

We assume j3 77 -equivalence for System F ffl types, which is important to make certain 
examples work as expected. Consider the following two signatures: 6 

signature A = {type t : * — >• ★; type u = fun a=>ta} 
signature B = {type u : * -> *; type t = fun a =>■ u a} 

Semantically, they are represented as: 

A = 3p 1 :Q.^Q..{t:[=p 1 :Cl^Q],u:[=Xa.p 1 a:Q.^Q]} 
B = 3ft:&->-a{u: [= ft : Q Q],t : [= Aa.ft a : £2 ft]} 

Intuitively, A < B is expected to hold (and vice versa). According to rules U-ABS and 
U-MATCH, this boils down to finding a type x : D. -> D. such that 

{t : [= ft : -> Q], u :[= A a. ft a : i2 -> Q]} < {u : [= x : Q. -> Q],t : [= Xa.xa : i2 -> Q]} 

By rule U-TYP, the following equivalences need to hold for a suitable choice of x: 

j3i = Xa.xa (viat) 
Xa.fiia = x (via u) 

In this and later examples, we use the syntax fun X => T to denote a type function in our 
imaginary Core language. 
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Substituting the solution for T, given by the second equation, into the first reveals that the 
following will have to hold: 

j3i = Xa.(Xa.j5i a) a 
Clearly, this is only the case under a combination of both j3- and 77 -equivalence. 

Module elaboration The module elaboration judgment (Figure 14), which has the form 
r h M : S ~* e, assigns module M the semantic signature S and additionally translates M 
to an Fa, term e of type S. (The invariant, r h e : E, determines elided pack annotations.) 
As in signature elaboration, the basic idea in module elaboration is to assign M an abstract 
signature 3a.E such that a represent all the abstract types that M defines. The difference 
here is that we must also construct the term e that has this signature — i.e., the evidence. 

One way to understand the evidence construction is to think of the existential type 3a. E 
as a monad that encapsulates the "effect" of defining abstract types. When we want to use 
a module of this abstract (think: monadic) signature, we must first unpack it (think: the 
bind operation for the monad), obtaining some fresh abstract types a and a variable x of 
concrete (think: pure) signature E. We can then do whatever we want with x, ultimately 
producing another module of (monadic) signature 3a! . E'. Of course, E' may have free 
references to the a, so at the end we must repack the result with the a to form a module 
of signature 3aa'.Y!. Thus, the abstract types a defined by M propagate monadically into 
the set of abstract types defined by any module that uses M. As many researchers have 
pointed out (MacQueen, 1986; Cardelli & Leroy, 1990), this monadic unpack/repack style 
of existential programming would be annoying to program manually. Fortunately, it is easy 
for module elaboration to perform it automatically. 

Figure 14 shows the rules for elaborating modules and bindings. The rules for pro- 
jections (M-DOT), module bindings (B-MOD), and binding sequences (B-SEQ) show the 
unpack/repack idiom in action. The last of these is somewhat involved, but only because 
ML modules allow bindings to be shadowed — a practical complication, incidentally, that 
is glossed over in most module type systems in the literature (with the exception of Harper 

6 Stone (2000), who account for full Standard ML). 7 It is here primarily that we rely on 
the fact that the F^ version from Section 3 allows shadowing in F, in order to avoid having 
to map external identifiers to fresh internal variables. (In fact, we have already relied on 
this for rule S-FUNCT, and do so again for rule M-FUNCT.) 

The rule M-FUNCT for functors is completely analogous to rule S-FUNCT for functor 
signatures (cf. Figure 1 1). Note that this rule and the sequence rule B-SEQ are the only two 
that extend the environment F, and that in both cases the new variable X is bound with a 
concrete signature E. As a result, when we look up an identifier X in the environment (rule 
M-VAR), we may assume it has a concrete signature. This is a key invariant of elaboration. 

The rules for functor applications (M-APP) and sealed modules (M-SEAL) both appeal 
to the signature matching judgment. In the former, the T represent the type components 

7 Of course, a realistic implementation of modules would want to optimize the construction of 
structure representations and avoid the repeated record concatenation. Such an optimization is 
fairly easy; it essentially boils down to partially evaluating the expressions generated by our 
sequencing rule. 
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Modules 



TV- M :Z ~-> e 



r(x) = z 

M-VAR 



F\-{B}:Z^e 



M-STRUCT 



T\-M:3a.{l x :£Ja" 



M-DOT 



r I- M.X : 3a. £ ~* unpack (a.y) — e in pack (a,y.lx) 
T\-S*~3a.T. r,a,X:ZhM:E-.£ 

M-FUNCT 

r h fun X:S^M : Va.Z -> E ~» Aa.AX:Z.e 

r(Xi)=\/a.£'^s r(x 2 ) = z ri-z< Ba.z'tT^/ 

rr-X 1 X 2 :S[r/a]-XiT(/X2) 

r(x) = z r h s ~> s ri-z<stT-*/ 



M-APP 



rhX:>5:S^pack (t,/X) 



M-SEAL 



Bindings TV- B :Z ^ e 

rhval *=£:{/*:[*]}-» {/* = [«]} " VAL 

rh r : t 

r h typeX=r : : [= t : jt]} ~» {/* = [t : k]} 
r h M : 3ce.£ ~> e L not atomic 



B-TYP 



r h module X=M : 3a. {/x : £} ~-> unpack (a,x) = e in pack (a, {lx = x}) 



B-MOD 



rh signature X=S : {l x : [= 2]} - {fc = [3]} 



T^PT B-SIG 



1 J B-INCL 

T I- include M : 3a.{l x :Z}^e 

— = B-EMT 

rhe:{}-{} 



TV-B l :3a l .{l Xl :T.i}^e l I ' =l Xl -l X: 



r, «i ,Xi : £i h £ 2 : 3a 2 .{/ X2 : £ 2 } - e 2 ^ C 

r h Bi ;S 2 : 3a 1 a 2 .{/^ 1 £ 2 } ^ unpack (ct] ,y x ) = e x 



B-SEQ 



unpack {a 2 ,y 2 ) = (let X x = y x .l X{ in e 2 ) in 

pack {aia 2 ,{l' Xl = y\ -l' x , > fr 2 = >'2-'x 2 }) 



Fig. 14. Module elaboration 
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Set ~» 

Xa.XElem : {t : [= a : £1], 

eq : [a x a — > bool], 
less : [a x a -> bool]}. 
pack (list a, 

/(letyi = {elem = [a : a]} in 
let>' 2 = 

let efem =yi.elem in 

let >21 = {set = [list a : £2]} in 

lety 2 2 = 

let set = j2l-set in 

in {elem = yi .elem, 
set = >>2-set, 
empty = >'2. empty, 
add = y2-add, 
mem = y2- mem }) 
)aj8.{set:[=j5:Q], elem:[=a:Q], empty:[j6], add:[axj3->j3], mem:[axj3^bool]} 

{module IS = Set Int; val s = IS. add (7, IS. empty)} ~> 

unpack (P,yi) = {IS = Set int (/' Int)} in 

letj 2 = (let/5 = yi.lS in {s = [IS. add (7,/S.empty)]}) in 

pack {/3,{IS = >' 1 .IS,s = y 2 .s}) 3/j { | S:{ } s . m 

Fig. 15. Example: module elaboration 



of the actual functor argument corresponding to the abstract types a declared in the for- 
mal argument signature. For instance, in the functor application in Figure 3, T would be 
simply int, since that is how the argument module defines the abstract type t declared 
in the argument signature ORD. This information is then propagated to the result of the 
functor application by substituting T for a in the result signature E. The sealing rule works 
similarly, except that T is not used to eliminate a universal type, but dually, to introduce an 
existential type. Hence, T is not propagated to the signature of the sealed module, but rather 
hidden within the existential. This makes sense because, of course, the point of sealing is 
to hide the identity of the abstract types a. 

Note that both M-APP and M-SEAL are made simpler by our language's restriction of 
functor applications and sealing to module identifiers (X1X2 and X:>S), which enables us 
to exploit the elaboration invariant that those identifiers (the X's) already have concrete 
signatures and need not be unpacked. As the let-binding encodings of the more general 
forms M\Mi and M:>S in Figure 2 suggest, elaboration of those forms just involves 
monadically unpacking the M's to X's first before applying M-APP or M-SEAL, and then 
repacking afterward. 

As an example of the module elaboration translation, Figure 15 sketches the result of 
elaborating the Set functor from Figure 3. It also shows the F^ representation of a simple 
program involving the application of this functor. We assume that there is a suitable library 
module Int that matches signature ORD, whose t component is transparently equal to int, 
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Set ~* 

Xa.XElem :{t:[=a: CI], 

eq : [a x a — > bool], 
less : [a x a -> bool]}. 
pack (list a, 

/(let e/em = [a : £2] in 
letsef = [list a : CI] in 
let erapfy = [nil] in 

let add = [. . .Elem.eq . . .Elem.\ess.. .] in 
let mem = [. ..Elem.eq . . .Elem.\ess. . .] in 

{elem = elem, set = set, empty = empty, add = add, mem = mem}) 
)aj3.{set:[=j3:n], elem:[=a:P_], empty:[/3], add:[axj3->/3], mem:[axj3^bool]} 

{module IS = Set Int; val s = IS. add (7, IS. empty)} ~-> 

unpack (j8,/5) = Set int (/'to) in 

let ^ = [/S.add (7,/S.empty)] in 

pack (p,{\S =IS,S = .v}) 3/3 . { |S:{...},S:[/J]} 

Fig. 16. Example: module elaboration, simplified 

and whose F ra representation is Int. In order to avoid too much clutter, we do not spell out 
the respective coercions / and /' occurring in both examples. 

To make the essence of the translation a bit more apparent, Figure 16 shows simplified 
versions of the same translations with all intermediate redexes (in particular, intermediate 
structures) removed, via straightforward j3 77 -transformations of let-bindings and records. 
In particular, once we eliminate the administrative overhead of rule B-SEQ, a structure 
simply becomes a sequence of let-bindings for the declarations in its body, feeding into a 
record that collects all bound variables as fields. 

Generativity Functors in Standard ML are said to behave generatively, meaning that 
every application of a functor F will have the effect of generating fresh abstract types 
corresponding to whichever types are declared abstractly in F's result signature. With the 
existential interpretation of type abstraction that we employ here, this generativity comes 
for free. Applying a functor produces a module with an existential type of the form 3a. E. 
Thus, if a functor is applied twice (say, to the same argument) and the results are bound 
to two different identifiers X\ and X2, then the binding sequence rule will ensure that two 
separate copies of the a will be added to the environment F — call them a\ and 0C2 — along 
with the bindings X\ : Y.\a\/a] andX2 : 1^2/0]. In this way, the abstract type components 
of X\ and X2 will be made distinct. 

In Section 7 we will explore an alternative semantics, where functors can be applicative, 
i.e., applying such a functor twice (to the same argument) will only produce one copy of 
the abstract types it defines. 

Path elaboration Figure 17 displays the last three rules of elaboration, concerning the 
elaboration of paths. (The elaboration rule for signature paths appeared in Figure 11.) 
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Paths |rhP:E^>7 

r h P : Bce.Z ^ e T h £ : Q, 



rh P : L ~* unpack (cn.x) = e inx 



P-MOD 



Types 



T\-P: 



rh r : t 



rhP: k--* T 



T-PATH 



Expressions 



r\-P:h]^e ^ 

— E-PATH 

T\- P: T^e.val 

Fig. 17. Path elaboration 



Paths are the means by which value, type, and signature components are projected out 
of modules. As explained in Section 2, in order for paths to make sense, the values, types, 
or signatures that they project out must be well-formed in the ambient environment F. In 
other words, paths P need to elaborate to a concrete signature E, because (unlike for module 
constructs) existential quantifiers can not be "extruded" further in the contexts where paths 
occur. To ensure this, the path elaboration judgment, r h P : E ~» e, uses the ordinary 
module elaboration judgment, r h M : E ~» e, in its premise (with M = P) to synthesize 
f's semantic signature 3a. E, which still allows "local" abstract types a to occur. It then 
checks that E does not actually depend on any of these a that P may have defined (note that 
we assume all types normalized, so any spurious dependencies are implicitly eliminated). 
The rules for type, expression, and signature paths use the path elaboration judgment to 
check the well-formedness of the path, and then project the component out accordingly. 

For instance, consider the example from Section 2 of an ill-formed path. Let M be the 
module expression 

{type t = int; val v = 3} :> {type t; val v : t} 

The semantic signature that module elaboration assigns to M is: 

3a. {t : [= a : Q],v: [a]} 

Thus, if we were to try to project either t or v from M directly, the resulting type or 
expression would not be well-formed, since both [— a : £1] and [a] refer to the local abstract 
type a that is not going to be bound in the environment F. If, on the other hand, we were to 
first bind M to an identifier X, and then subsequently project out X.t orX.v, the paths would 
be well-formed. The reason is that the binding sequence rule would extend the ambient 
environment with a fresh a, as well as X : {t : [— a : £2], v : [a]}. Under such an extended 
environment, X.t would simply elaborate to a, and X.v would elaborate to X.v.val of type 
a, both of which are well-formed since a is now bound in the environment. In general, 
since identifiers have concrete signatures, any well-formed module of the form X.ly will 
also be a well-formed path. 

If one views existential types as a monad, as we have suggested, then the path elaboration 
rule may seem superficially odd because it allows one to "escape" the monad by going from 
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3a.E to E. However, the point is that one can only do this if the "effects" encapsulated by 
the monad — i.e., the abstract types a defined by the path — are strictly local. This is similar 
conceptually to the hiding of "benign" (or "encapsulated") effects by Haskell's runST 
mechanism (Launchbury & Peyton Jones, 1995). 



5 Meta-theoretic properties 

Having defined the semantics of ML modules by elaboration into System F ffl , it is time to 
prove it (a) sound, and (b) decidable. 

Some theorems about the module language depend on the assumption that respective 
properties can be proved for core language elaboration (i.e., the first three judgments listed 
in Figure 8). However, because both language layers are mutually recursive through the 
syntax of paths (and after Section 6, also through modules as first-class values), these 
proofs are typically not independent — they need to be performed by simultaneous induc- 
tion on the derivations for both language layers. We hence state all properties that we 
assume about the core language as part of the respective theorems below. The theorems 
then hold provided that the inductive argument can also be shown for all additional cases 
not specified by our grammar for types T and expressions E. 



5.1 Soundness 

Proving soundness of a language specified by an elaboration semantics consists of two 
steps: 

1. Showing that elaboration only produces well-typed terms of the target language. 

2. Showing that the type system of the target language is sound. 

Fortunately, in our case, since the target language is the very well-studied System Fo, we 
can simply borrow the second part from the literature. It thus remains to be shown that the 
elaboration rules produce well-formed F ffl expressions. Of course, since our development 
is parametric in the concrete choice of a core language, the result only holds relative to 
suitable assumptions about the soundness of the elaboration rules for the core language. 

Formally, we state the following theorem, which collects the elaboration invariants al- 
ready stated in Figure 8: 

Theorem 5.1 (Soundness of elaboration) 
Provided T h □ we have: 

1. If T h T : K ~» T, then rh T : K. 

2. If T \-E : T ~» e, then T h e : X. 

3. If T h T < t' ~» / and T h T : £2 and T h %' : £2, then T h / : T -> t'. 

4. If T h S/D ~» S, then T h E : £2. 

5. lfT\-P/M/B:Z~^e, thenrhe:E. 

6. If T h S < S' ~» / and T h S : £2 and T h S' : £2, then T h / : E -> E'. 

7. If T h E < 3a.H t T / and T h E : £2 and T,a h E' : £2, 
then r h T : K a and T h / : E ->• E'[r/a]. 
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The proof is by relatively straightforward simultaneous induction on derivations. The argu- 
ments for properties 1-3 clearly depend on the core language, and we assume that it can be 
proved for all additional cases not specified in our grammar. We have performed the entire 
proof in Coq (Section 10), and transliterate only two representative cases here: 

• Case M-APP: By induction we know that (1) r h T : K a and (2) T h / : E -> E'[r/a]. 
From (1) we can derive that r h X\ T : (L' -> E)[r/a]. From (2) it follows that 
rh/X 2 : E'pr/a]. Thus, we can conclude T\- X\X (f X 2 ) : S[r/a] by the typing 
rule for application. 

• Case B-SEQ: By induction on the first premise we know (1) T h e\ : 3ai.{/ Xl : Ei}. 
Let Ti = r,ai,Xi:Ei. By validity and inversion, from (1) we derive T, OL\ h Ei : Q, 
so Ti h □. By induction on the second premise, (2) Ti h e2 : 3a~i.{lx 2 : E2}. It is 
easy to show r,ai,yi :{/;£] : Ei} h yi./x, : Ei. By convention, y\ andj2 are fresh, and 
so it follows thatr,ai,yi:{/ Xl : Ei}, a 2 ,yr-{h 2 : £2} = y\.l' X{ M 2 = y2-lx 2 }- 
{l' Xl : Ej,/x 2 : E2} from the typing rules. From (1) and weakening (2), the overall 
goal follows by inner induction on the lengths of a\, a 2 , and l Xl , and expanding the 
n-ary versions of pack, unpack and let. □ 

If the reader finds the proof cases shown here to be boring and straightforward, that 
is because they are! The remaining cases are even more boring. In other words, there is 
nothing tricky going on in our elaboration — which substantiates our claim that it is simple. 

5.2 Decidability 

All our elaboration rules are syntax-directed, and they can be interpreted directly as a 
deterministic algorithm. Provided core elaboration is terminating, this algorithm clearly 
terminates as well. 

There is one niggle, though: the signature matching rule requires a non-deterministic 
guess of suitable instantiating types T. To prove elaboration decidable, we must provide a 
sound and complete algorithm for finding these types. It's not obvious that such an algo- 
rithm should exist at all. For example, consider the following matching problem (Dreyer 
etal, 2003): 

Va.[=a:ic]->[=Ti:K / ] < 3j3.([= J3 : k] -> [= t 2 : k']) 

The matching rule must find an instantiation type % : K for j3 such that the left signature is a 
subtype of [= T : k\ -> [= T2[t/J3] : k'], which in turn will only hold if Ti[r/a] = T2[t/J3]. 
Since K may be a higher kind, this amounts to a higher-order unification problem, which 
is undecidable in general (Goldfarb, 1981). 

Validity Fortunately, under minimal assumptions about the initial environment, we can 
show that such problematic cases never arise during elaboration. More precisely, we can 
show that, whenever we invoke E < 3a. E', the target signature E' has the property that each 
abstract type variable a e a actually occurs explicitly in E' in the form of an embedded type 
field [= a : K a ]. We say that a is rooted in E' in this case. An abstract signature in which all 
quantified variables are rooted is called explicit. Intuitively, the reason we can expect the 
target signature 3a.l! to be explicit is that (1) the only signatures we ever match against 
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a rooted in E :<S> a rooted in E 

a rooted in [= t : k] (at e) :<^> a = t 

a rooted in {/ : E} (at /./') :<^> a rooted in {I : E}J (at /') 

[t] explicit (always) [t] valid (always) 

[= T : k] explicit (always) [= T : k] valid (always) 

[= E] explicit :<^> E explicit [= S] valid :<^> E explicit 

{/ : E} explicit :<S> E explicit {/ : E} valid :<S> E valid 

Va.E — > E explicit :<S> 3a. E explicit A E explicit Va.E^E valid :<S> 3a.E explicit A E valid 

3a.E explicit :<S> a rooted in E A E explicit 3a.E valid :<S> E valid 

r h E : explicit T h E : Q. A E explicit rhS:fl valid :<^> T h E : £2 A E valid 

T valid :<s> V(X:E) € F, E valid 
Fig. 18. Signature explicitness and validity 

during elaboration are themselves the result of elaborating some ML signature S, and (2) 
all of such a signature's abstract types a must originate in some opaque type specification 
appearing in S. 

Figure 18 gives an inductive definition of these properties. (We typically drop the explicit 
path description "(at /)" from the rootedness judgment — the only place where we actually 
need it will be the definition of signature normalization in Section 6.) 

However, this is not all. While it is necessary (in general) that a signature E is explicit 
to decide matching L < S, it is not sufficient. Subtyping is contra-variant in functor argu- 
ments, so we also need to ensure that, whenever we invoke subtyping to determine whether 
£ < £' and E is a functor signature, its argument signature is explicit as well. Unfortunately, 
we cannot require all of E to be explicit, because not all module expressions (as opposed 
to signature expressions) yield explicit signatures. For example, 

let module A = {type t = int; val v = 5; val f x = x} 

:> {type t; val v : t; val f : t -» int} 
in {val f = A.f; val v = A.v} 

defines a module with the non-explicit signature 3a. {f : [a — > int],v : [a]}. 

Figure 18 hence defines the second notion of a valid signature that captures the relevant 
property — that is, a signature is valid if all contained functor arguments are explicit (but 
other constituent signatures need not be). Intuitively, it is expected that modules have valid 
signatures, because the language requires explicit signature annotations on all functor ar- 
guments. The notion of validity is extended to environments, and we require all signatures 
and environments used in elaboration to be valid. 8 Note that validity of environments only 
cares about variables bound to concrete signatures E because of the elaboration invariant 
(discussed in Section 4, "Module elaboration") that all modules of signature 3a.E are 
unpacked into a and X : E before being added to the context. 



The notions of explicit and valid signatures are also called analysis and synthesis signatures in the 
literature (Dreyer et al, 2003; Rossberg & Dreyer, 2013); Russo (1998) used the terms solvable 
and ground. 
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lookup(*(£,£' 



)tf 



iflookup a (L,E')U 



lookup a ([= t : k], [= t' : k]) f t if t' = a 

lookup a ({/TL},{/' :Z'})tT if3/e7nF. lookup a ({ZTS}./, {/' : £'}./) f T 
Fig. 19. Algorithmic type lookup 

With a little auxiliary lemma, we can show that our elaboration establishes and maintains 
explicit signatures for signature expressions, and valid signatures for module expressions: 

Lemma 5.2 {Simple properties of validity) 

1 . If E explicit, then E valid. 

2. If E explicit/valid, then E[t/o~] explicit/valid. 

Lemma 5.3 {Signature validity) 
Assume F valid. 

1 . If T h S/D ~» S, then E explicit. 

2. If r h P/M/B : S ~» e, then E valid. 

Type lookup If the 3a. E' in the matching rule U-MATCH is explicit, then the instantiation 
of each a can be found by a simple pre-pass on E and E', thanks to the following obser- 
vation: if the subsequent subtyping check is ever going to succeed, then E must feature an 
atomic type signature [= % : K a ] at the same location where a is rooted in E'. Moreover, a 
must be instantiated with a type equivalent to T. 

Consequently, the definition of lookup in Figure 19 implements a suitable algorithm for 
finding the types T in rule U-MATCH, through a straightforward parallel traversal of the two 
signatures involved. There is a twist, though: an abstract type variable may actually have 
multiple roots in a signature. For example, the external signature {type t; type u = t} 
elaborates to 3a. {f : [= a : Q],u : [= a : Q]}. The lookup algorithm, as given in the figure, 
is non-deterministic in that it can pick any suitable root — specifically, the choice of / in the 
last clause is not necessarily unique. This formulation simplifies the proof of completeness 
below. Intuitively, it does not matter which one we pick, they all have to be equivalent. The 
soundness theorem proves that, but first we need a little technical lemma: 

Lemma 5.4 {Simple properties of type lookup) 

1 . If lookup^E, E') t T, then fv(r) C fv(E). 

2. If lookup ff (E,E') t T and an a! = 0, then lookup s -(E,E'[T / /a']) |t 
(and both derivations have the same size). 

3. If lookup^ (E, E') t T and T h E : £2, then TVxTk. 

Theorem 5.5 {Soundness of type lookup) 

1. LetrhE:£2andr,ahE':£2. If lookup a (E,E') t Ti, then T h n : K a . 
Furthermore, if F h E < H'fo/a] for r h T2 : K a , then Ti = T2. 

2. Let T h E : £2 and T, a h E' : £2. If lookup ff (E,E') t Ti, then r F tJ : K a . 
Furthermore, if T h E < 3a.E' t T2, then Ti = T2. 



Proof 
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Part 1 is by easy induction on the size of the derivation of the lookup. Part 2 follows by 
induction on the length of a. When a is empty, then there is nothing to show. Otherwise, 
a = a, a' and Ti = Ti , x\ , such that lookup a (E, If) f Tj and lookup ff (E, E') t t'j . Let r' = 
r,a'. With weakening, respectively reordering, r' h E : £2 and Y',a h E' : £1 By part 1, 
we then know r' h Ti : JC a . Lemma 5.4 implies fv(Ti) C fv(E), and because E is well- 
formed under T, it follows that fv(Ti) C dom(r), so that we can strengthen to T h~ Ti : K a . 
Substitution yields Y' h E'[Ti/a] : £2, and from Lemma 5.4 we get lookup^ (E,E'[ti /a}) f 
Tj, such that we can apply the induction hypothesis to conclude T\- t[: K a >. 

Furthermore, in order to prove the type equivalence, we first invert U-MATCH to reveal 
r h E < E'[T2/a] and Th T2 : K a . Consequently, T2 = T2,T 2 and fv(T2) C dom(r), i.e., 
anfv(T2) = 0by the usual conventions. The latter implies E'[T2/a] = E'[T2/a][T 2 /a'] = 
E'pf 2 /a'][T2/a]. Similar to before, Lemma 5.4 gets us lookup a (E,E'[T 2 /a']) t Ti, and 
substitution r, a h E'[T 2 /a'] : i2. By part 1, Ti = T2 then. To invoke the induction hypoth- 
esis for concluding t'j = T 2 as well, we first note that by substitution, Y' h E'[T2/a] : i2, 
and second, by Lemma 5.4 again, lookup s /(E,E'[T2/a]) t Third, since E'[T 2 /a] = 
E'[f 2 /a'][T2/a], we can construct a derivation for Y h E < 3a'.E'[T 2 /a] f ^ 2 with rule 
U-MATCH. □ 

According to soundness, if there is any type at all that makes a match succeed, then 
lookup can only deliver a well-formed, equivalent type. Despite being non-deterministic, 
the result of lookup hence is unique: 

Corollary 5.6 {Uniqueness of type lookup) 

Let T h E : Q. and Y h 3a. H : £2 and Y h E < 3a.E' t T. If lookup ff (E,E') t Ti and 
lookup ff (E, E') t T2, then Ti = T2. 

Because of this result, we can implement lookup as a deterministic algorithm by simply 
choosing the "first" root we encounter for each type variable, in any signature traversal 
order of our liking. 

For explicit signatures, our definition of type lookup is also a complete algorithm for 
finding instantiations in the matching judgment: 

Theorem 5.7 (Completeness of type lookup) 
Assume 3a. E' explicit. 

1. If T h E < E'[r/a] and aea, then lookup a (E,E') t a[t/a}. 

2. If T h E < 3a. U t T, then lookup ff (E, E') j" T. 

Proo/ 

Explicitness of 3a. I! implies a rooted in E', which in turn implies a rooted in E'. Part 1 
is then proved by simple induction on the derivation of a rooted in E'. Part 2 follows as a 
straightforward corollary. □ 

Note that this proof relies on the ability of the lookup algorithm to non-deterministically 
pick the root at the same path that was used in the respective derivation of a rooted in 
E'. Combined with Uniqueness we know that any other path — and thus a deterministic 
choice — would work as well. Which gives us: 



Corollary 5.8 (Decidability of matching) 
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Assume that F is valid and well-formed, and r h T < t' / is decidable for types well- 
formed under F. If E valid and 3 explicit, and both are well-formed under F, then r h E < 
3 t T / is decidable (and does not actually require checking well-formedness of types). 

This result follows directly, because subtyping and matching is defined by induction on 
the structure of the semantic signatures, and this structure remains fixed under type sub- 
stitution, as performed in rules U-MATCH and U-FUNCT. (We don't need to check the 
well-formedness of T in U-MATCH because via Lemma 5.4, it is a consequence of looking 
up the types in the well-formed signature E.) 

From there, decidability of elaboration follows because, up to matching, elaboration is 
syntax-directed: 

Corollary 5.9 (Decidability of elaboration) 

Under valid and well-formed F, provided we can (simultaneously) show that core elabora- 
tion is decidable, all judgments of module elaboration are decidable as well. 

5.3 Declarative properties of signature matching 

Finally, we want to show that signature matching has the declarative properties that you 
would expect from a subtype relation, namely that it is a preorder. These properties are not 
actually relevant for soundness or decidability of the basic language, but they provide a 
sanity check that the language we are defining actually makes sense. They are also relevant 
to our translation of modules as first-class values (Section 6), and for the meta-theory of 
applicative functors (Section 9). 

One complication in stating the following properties is that subtyping is defined in terms 
of the core language subtyping judgment F h z < %' ~» e. Most of the properties only hold 
if we assume that the analogous property can be shown for that judgment. To avoid clumsy 
repetition, we leave this assumption implicit in the theorem statements. 

First, we need a couple of technical lemmas stating that subtyping is stable under weak- 
ening and substitution: 

Lemma 5.10 (Subtyping under Weakening) 
Let r' D r and F' h □. 

1. If Tl- S < S' ~» /, then F 1 h 3 < 3' ~» /. 

2. IfrhE<StT->/,thenr'hE<StT-->/ 

(Moreover, the derivations have the same size, up to core language judgments.) 

Lemma 5.11 (Subtyping under substitution) 
LetTh z : K a . 

1. If F,a h 3 < 3' ~» /, then F h E[z/a] < S'pr/a] ~» f[z/a]. 

2. If T, a h E < 3 1 t' ~» /, then T h E[r/a] < 3 [z/a] t t' [z/a] f[z/a\ . 

(Moreover, the derivations have the same size, up to core language judgments.) 
Now for the actual theorems: 



Theorem 5.12 (Reflexivity of subtyping and matching) 
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1. If T h S : £2, then r h E < E -w /. 

2. Ifr,ahE:i2,thenr,al-E<3a.Eta->/. 

Proo/ - 

By simultaneous induction on the structure of E and E, respectively. □ 

Theorem 5.13 (Transitivity of subtyping and matching) 

1 . If r h S : £2 and T h E' : £2 and T h S" : £2 and T h E < S' /' and T h E' < E" ~* /", 
then r h E < Z" ~* f. 

2. If T h E : £2 and T h 3a! .E' : £2 and T h 3a" .L" : £2, and T h E < 3a' .E' t t' ~* /' 
and T, a' h E' < 3a" U 1 1 t" ~* /", then T h E < 3a".E" t T ~* /. 

Proo/ - 

Since matching is syntax-directed, the proofs are a relatively straightforward simultane- 
ous induction on the cumulative size of the subtyping/matching derivations (up to core 
language rules). In part (2), we need to apply the above substitution lemma. □ 

A further property one might expect from a subtyping relation is antisymmetry, i.e., if 
E < E' and E' < E (which we will abbreviate as E <> E'), then E = E'. This does not hold 
directly in our system, because the ordering of quantified variables might differ. We defer 
discussion of antisymmetry to the next section, where we will prove it in a slight variation. 

6 Modules as first-class values 

ML modules exhibit a strict stratification between module and core language, turning mod- 
ules into second-class entities. Consequently, the kinds of computations that are possible on 
the module level are quite restricted. Extending the module system to make modules first- 
class leads to undecidable typechecking (Lillibridge, 1997). However, it is straightforward 
to allow modules to be used as first-class core values after explicit injection into a core 
type of packaged modules (Russo, 2000). In fact, in our setting, the extension is almost 
trivial. 

Syntax Figure 20 summarizes the syntax added to the external language. We add package 
types of the form pack S to the core language. These are inhabited by packaged modules 
of signature S. Correspondingly, there is a core language expression form pack M:S that 
produces values of this type. To unpack such a module, the inverse form unpack E:S is 
introduced as an additional module expression. It expects £ to be a package of type pack S 
and extracts the constituent module of signature S. (This is more liberal than the closed- 
scope open expression of Russo (2000).) 

Why all the signature annotations? To avoid running into the same problems as caused by 
first-class modules, we do not assume any form of subtyping on package types (even if the 
core language had subtyping). That is, package types are only compatible if they consist 
of equivalent signatures. The type annotation for pack ensures that packaged modules 
still have principal types under these circumstances, so that core type checking is not 
compromised. For unpack, the annotation determines the type of £ — which is necessary 
if we want to support ML-style type inference in the core language (but could be omitted 
otherwise). 
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(types) T ::= ... | pack 5 

(expressions) E ::= ... | packM:5 
(modules) M ::= ... | unpack E:S 

Fig. 20. Extension with modules as first-class values 

Elaboration Figure 21 gives the corresponding elaboration rules. Let us ignore the use 
of signature normalization norm(E) in these rules for a minute and think of it as the 
identity function (which, morally, it is). Then a module M and its packaged version have 
essentially the same F ffl representation, as a term of existential type. Consequently, elab- 
oration becomes almost trivial. A package type simply elaborates to the very existential 
type that represents the constituent signature. Packing has to check that the module's 
signature actually matches the annotation and coerce it accordingly. Unpacking is a real 
no-op: there is no subtyping on package types, so the type of E has to coincide exactly 
with the annotated signature. No coercion is necessary. 

Signature normalization So what is the business with normalization? Unfortunately, were 
we to just use an unadulterated signature to directly represent its corresponding package 
type, the typing of packaged modules would become overly restrictive. Consider the fol- 
lowing example: 

signature A = {type t; type u} 
signature B = {type u; type t} 
val f = fun p : (pack A) => . . . 
val g = fun p : (pack B) => f p 

Intuitively, the signatures A and B are equivalent, and in fact, their semantic representations 
are mutual subtypes. But these representations will not actually be equivalent System F ra 
types — A elaborates to 3a\(X2.{t : [= oti : Q],u : [= : £2]} and B to 3o£2«i-{t : [= OCi : 
£2],u : [= 0I2 : £2]} according to our rules (cf. Figure 11). In the module language this is 
no problem: whenever we have to check a signature against another, we are using coercive 
matching, which is oblivious to the internal ordering of quantifiers. But in the core language 
no signature matching is performed; package types really have to be equivalent Fo types in 
order to be compatible. In that case, the order matters. So the definition of g above would 
not type check. 

To compensate, our elaboration must ensure that two package types pack Si and pack S2 
translate to equivalent F^ types whenever S\ and S2 are mutual subtypes. Toward this end, 
we employ the normalization function defined in Figure 22. All this function does is put 
the quantifiers of a semantic signature into a canonical order. For example, for a signature 
3a. T., normalization will sort the variables a according to their (first) appearance as a root 
in a left-to-right depth-first traversal of E. In order to make this well-defined, we impose a 
fixed but arbitrary total ordering on the set of labels /, which we extend to a lexicographical 
order on lists 7 of labels. Further, we assume a meta-function sort< which sorts its argument 
vector according to the given (total) order <. We instantiate it with an ordering a\ <z OC2 
on type variables (also defined in Figure 22) according to their "first" occurrence as a root 
in £ — expressed by reference to the "(at 7)" part of the rootedness judgment. 

Note that normalization is defined only for explicit signatures (Section 5.2), where 
every variable is rooted. However, that is fine because we only need to normalize the 
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Types 



r h pack 5 : ft ~» norm(E) 



— T-PACK 



rh T : K^f t 



Expressions 



r h M : E 



n-s~»s 



rhS'<norm(S)^/ 



r h pack M:5 : norm(S) /e 



E-PACK 



Modules 



T\- M :E e 



ri-s~»s 



T\- E : norm(S) ~» e 



M-UNPACK 



r h unpack £:5 : norm(S) ~* e 
Fig. 21. Elaboration of modules as first-class values 

representations of signatures appearing as annotations on pack or unpack. In the base case 
of atomic value signatures [t], we assume that a similar normalization function norm core (T) 
exists for normalizing core-level types according to core-level subtyping r h T < t'. (For 
instance, for ML this core type normalization would canonicalize the order of quantified 
type variables in polymorphic types.) 

It is not difficult to show the following properties: 

Lemma 6.1 {Signature normalization) 

Assume fv(norm core (T)) = fv(r) and norm core (T'[f/a]) = norm core (T')[f/a]. Then: 

1. fv(norm(E)) =fv(S) 

2. norm(S[f/a]) = norm(S)[r/a]. 

3. If E explicit, then norm(E) explicit. 

4. If T h S : £1, then F h norm(S) : Q.. 

5. If E explicit, then r h E <> norm(E). 

The main result regarding normalization, then, is a form of anti-symmetry for subtyping. 
But first, a technical lemma that we need for the proof. It effectively says that two abstract 
signatures mutually matching each other quantify, up to reordering and renaming, the same 
abstract type variables. 

Lemma 6.2 (Mutual matching) 

Suppose a rooted in E and a' rooted in £'. Moreover, a n fv(r) = a' n fv(f') = 0. If 
T, a h E < E'pf'/a'] and inversely, T,a' h E' < E[r/a], then [r/a] = [f'/a'] -1 , i.e., \a\ = 
\a'\, and there is a reordering a" of a', and a corresponding reordering t" of t', such that 
T = a" and f " = a. 

Proof 

For every a' <G a', we can show by induction on its rootedness derivation that there are 
atomic type signatures with r, a h [— To : k] < [= a'[f' /a'} : K"], and conversely, F,a' h 
[= a' :k]< [= To[t/os] : Jf]. By inverting those subtypings, To = a'pf'/a'], and at the same 
time a' = tq[t/(x]. That is, a' = a' [t'/«'] [x/a] . Since a' € a', there is a corresponding 
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norm([-r]) 
norm([= t : k]) 



= [norm core (-r)] 
= [=t:k] 
= [= norm(B)] 



norm([= 5]) 
norm({7 : £}) 



= {/ : norm(Z)} 
-) = Va'.norm(L) — > norm(E) where a' = sort< n . (a) 
= 3a'.norm(Z) where a' = sort< n .„ (a) 



norm(Va.Z — > E 
norm(3a.Z) 



min{/ | ai rooted in Z (at /)} < min{/ | 0C2 rooted in L (at /)} 



Fig. 22. Signature normalization 



t' e t', such that a' — T'[r/a]. Because t' 7^ a' according to the assumptions about fv(r'), 
there has to be an a € a, such that t' = a and a[z/a\ = a'. We can prove the same for 
every other a' e a'. Consequently, because all a' are distinct, all %' have to be distinct, 
too, and thus \a\ > \a'\. By symmetry, i.e., exchanging roles and repeating the argument, 
we obtain that both substitutions have the same cardinality and are mutual inverses. □ 

Theorem 6.3 (Anti-symmetry of subtyping up to normalization) 

Let r h E : Q. explicit and r h S' : Q. explicit. Furthermore, assume that if F h T : and 
r h t' : and T h T <> t', then norm core (T) = norm core (T'). Then, if both T h S < S' and 
r h S' < S, it holds that norm(S) = norm(E'). 



By induction on the (size of the) derivations. In the cases of rules U-ABS and U-FUNCT, 
invert the matching premise and apply the previous lemma to reveal that the quantified 
variables are equivalent up to reordering (and a-renaming). Hence, we can assume (after 
a-renaming) that both inner signatures are well-formed under the same extension of F, and 
apply the induction hypothesis to know that their normalizations are equal. Since sorting 
of the variables is independent of the original quantifier order as well, it also produces the 
same result for both sides. □ 

By normalizing semantic signatures in all places where they are used as package types, 
we hence establish the desired property that the intuitive notion of signature equivalence 
coincides with type equivalence. By applying the coercion / in the rule for pack, we also 
ensure that the representation of the module itself is normalized accordingly. 

Soundness The package semantics is so simple that soundness is an entirely straightfor- 
ward property. 

Theorem 6.4 (Soundness of elaboration with packages) 
Theorem 5.1 still holds with the additional rules from Figure 21. 

Proof 

By simultaneous induction on derivations. The existing cases are all proved as before; the 
new ones are straightforward given Lemma 6. 1. □ 



Proof 



Our decidability result (Corollary 5.9) is not affected by the addition of modules as first- 
class values, because it only hinged on the decidability of signature matching. 
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6.1 A note on first-class modules 

Given that our elaboration of modules as first-class values does not actually do much, the 
reader may be puzzled why it is allegedly so much harder to go the whole way and make 
modules truly first-class. Can't we just merge the module and core levels into one unified 
language? For some constructs, such as conditionals, this would probably require type 
annotations to maintain principal types, and ML-style type inference certainly would not 
work anymore. But those are limitations that other languages with subtyping (especially 
object-oriented ones) have always been comfortable with. In the ML module literature, 
however, it has been frequently claimed that first-class modules result in undecidable type 
checking (Lillibridge, 1997), so surely there must be more fundamental problems. What, 
specifically, would break in the F-ing approach? 

A move to first-class modules means collapsing module and term language, as well as 
signature and type language. Because types can be denoted by type variables, the latter 
would imply that signatures can then also be denoted by type variables. Our elaboration, 
on the other hand, is dependent on one fundamental property: for any signature occurring 
in the rules, the number of abstract types it declares — i.e., the number of quantifiers — is 
known statically and stable under substitution. If this were not the case, then we could not 
perform the implicit lifting (or "monadic" binding) of existentials that is so central to our 
approach. Clearly, if we allowed for type variables as signatures, it would no longer work. 

Moreover, as Lillibridge (1997) showed, we would lose decidability of subtyping. Look- 
ing at our subtyping rules, they substitute type variables along the way. With type variables 
possibly representing signatures, substitution could change the structure of the signatures 
we are looking at. Consequently, the subtyping rules would no longer describe an algorithm 
that is inductive on the structure of signatures, and (backwards) application of the rules 
might indeed diverge (see Lillibridge (1997) for an example). That is, the argument we 
made regarding Corollary 5.8 (Decidability of matching) would no longer hold. 

The sort of "predicativity" restriction that results from separating types and signatures 
(i.e., signatures can only abstract over types, not other signatures) is thus crucial to main- 
taining decidability of typechecking. It is the real essence of the core/module language 
stratification in ML. Without it, the F-ing approach would not work — nor are we aware of 
any other decidable type system for ML-style modules without a similar limitation. 

The same problems would arise if we were to add abstract signature declarations of the 
form signature X to the language. Indeed, it is the presence of this additional feature that 
tips the scales and renders OCaml's module type checking undecidable (Rossberg, 1999). 



7 Applicative functors and static purity 

The semantics for functors that we have presented so far follows Standard ML, in that 
functors are generative: if a functor body defines any abstract types, then those types 
are effectively "generated" anew each time the functor is applied. OCaml employs an 
alternative, so-called applicative semantics for functors, by which a functor will return 
equivalent types whenever it is applied to the same argument. For example, consider the 
following use of the Set functor (cf. Figure 3): 
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val pi = pack {type t = int; val v = 6} : {type t; val v : t} 

val P2 = pack {type t = bool; val v = true} : {type t; val v : t} 

module Flip = fun X : {} => unpack (if random() then pj else P2) : {type t; val v : t} 

Fig. 23. Example: a statically impure functor 

module IntOrd = {type t = int; val eq = Int.eq; val less = Int. less} 

module Set! = Set IntOrd 

module Set2 = Set IntOrd 

val s = Seti.add (7, Set2. empty) 

The last line in this example does not typecheck under generative semantics, because each 
application of Set yields a "fresh" set type, such that Set;. set and Set2.set differ. Under 
applicative semantics, however, the example would typecheck, because the two structures 
are created by equivalent module applications. 

The applicative functor semantics enables the typechecker to recognize that abstract data 
types generated in different parts of a program are in fact the same type. This is particularly 
useful when working with functors that implement generic data structures {e.g., sets), but 
it also supports a more flexible treatment of higher-order functors. For more details about 
these motivating applications, see Leroy (1995). 

Unfortunately, applicative functor semantics is also significantly subtler than generative 
semantics, and much harder to get right. In particular, there are two major problems: 

Type safety: For a functor to be safely given an applicative semantics, it must at a min- 
imum satisfy the property that the type components in its body are guaranteed to be 
implemented in the same way every time the functor is applied to the same argument. In 
the presence of modules as first-class values (Section 6), this property is not universally 
satisfied. For example, consider the functor Flip in Figure 23. The first time this functor 
is applied, it may return a module whose type component t is implemented internally as 
int, whereas the second time t may be implemented as bool. It is thus utterly unsound 
{i.e., breaks type safety) to give a functor like Flip an applicative semantics. 

Abstraction safety: Even if the type components of a functor are implemented in the 
same way every time it is applied, treating the functor as applicative may nevertheless 
constitute a violation of data abstraction. That is, for some abstract data types imple- 
mented by a functor, applicative semantics breaks the ability to establish representation 
invariants locally. We will discuss this problem in more detail and see examples in 
Section 8. 

Concerning the first of these two problems, both Moscow ML and (more recently) 
OCaml provide packaged modules and applicative functors, and circumvent the soundness 
problem only by imposing severe (and rather unsatisfactory) restrictions on the unpacking 
construct, namely prohibiting its use within functor bodies. In this section, we focus on the 
first problem and show how to address it properly within the F-ing modules framework. 
The second problem will be explored in Section 8. 

7.1 Understanding applicativity vs. generativity in terms of purity 

For the purpose of ensuring type safety, the key thing is to ensure that we only project 
type components out of module expressions whose type components are statically well- 
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(signatures) S ::= ...\{X:S)^>S 
Fig. 24. Extending the syntax of the module language with applicative functor signatures 

determined. Following Dreyer (2005), we refer to such expressions as statically pure, 
which for the remainder of this section we will just shorten to pure. (We will consider 
the role of dynamic purity in Section 8.) 

In our module language, the expression that introduces static impurity is the unpack E:S 
construct: the type components of the unpacked module depend essentially on the term E, 
a term which may have computational effects that lead it to produce values with different 
type components every time it is evaluated. If an unpacked module appears in the body of 
a functor, the functor will encapsulate the impurity. 

Thus, we need to distinguish between pure functors and impure functors. And it is 
precisely the pure ones that may behave applicatively, while the impure ones have to behave 
generatively. Hence, from here on, when talking about functors, we will use "applicative" 
interchangeably with "pure", and "generative" interchangeably with "impure". (In fact, the 
correspondence is so natural and intuitive that we are tempted to retire the "applicative" 
vs. "generative" terminology altogether. For historic reasons, however, we will continue to 
use the traditional terms in the remainder of this article.) 

One important point of note: in the case where £ is a value (or more generally, free of 
effects), it would seem that there is nothing unsafe about projecting type components from 
unpack E:S, since each unpacking will produce modules with the same underlying type 
components. The trouble with permitting unpack E S to be treated as statically pure — even 
in this case — is that, while its type components are well-determined, they are not statically 
well-determined. In the parlance of Harper, Mitchell & Moggi (1990), unpack E:S does 
not obey phase separation because the identity of its type components may depend on the 
dynamic instantiation of the free (term) variables of E. As a result, supporting projection 
from unpack E:S would require full-blown value-dependent types, which we would like 
to avoid for a variety of pragmatic reasons. The F-ing modules approach, by virtue of its 
interpretation into the non-dependently-typed F ffl , has the benefit of providing automatic 
enforcement of phase separation, and thus prohibits projection from unpack E:S. 



7.2 Extending the language 

In order to distinguish between pure (a.k.a. applicative) and impure (a.k.a. generative) 
when specifying a functor — e.g., in a higher-order setting — we extend the syntax of the 
external language of signatures with a new form of functor signature, shown in Figure 24. 
While the original form retains its meaning for specifying impure functors, the new one 
specifies pure ones. For example, the (pure) Set functor matches the pure functor signature 
(X : ORD) => SET, while the (impure) Flip functor will only match the impure signature 
(X : {}) — > {type t; val v : t}. That said, Set will also continue to match the impure 
signature (X : ORD) — > SET, because pure (applicative) functor signatures are treated as 
subtypes of impure (generative) ones. 

One defining feature of applicative functors is the ability to project types from module 
paths containing functor applications. For example, given the familiar pure Set functor, 
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(Set lntOrd).set should be a valid type expression, because every application of Set returns 
the same type. Since our syntax of paths P has been maximally general from the outset, it 
readily allows such types to be written. In fact, we will see shortly that the existing seman- 
tics for paths does not need to change much in order to encompass functor applications. 

7.3 Elaboration 

The addition of applicative functors, along with the attendant tracking of purity, requires 
some significant changes to elaboration. We will walk through those changes starting with 
the simple parts. 

Semantic signatures The main difference between a generative and an applicative functor 
is the point at which the abstract type components in their bodies get created, and this 
difference is reflected quite clearly in the placement of existential quantifiers in their 
semantic signatures. A generative functor has an F m type of the form Vcfi.Ei — > 3a?. £2- 
Applying such a functor produces an existential package, which must be explicitly un- 
packed in order to get access to the type components of the package; however, due to 
the closed-scope nature of existential unpacking, there is no way to associate those type 
components with the existential package (and thus the generative functor) itself. In contrast, 
following Russo (1998), we will describe applicative functors with F^, types of the form 
3a2-V«i .Ei — > T.2- Such signatures indicate that the existential package is constructed only 
once, when the functor is defined, not every time it is applied, thus enabling the abstract 
types 02 to be associated with the functor itself. The return type of an applicative functor 
is always a concrete signature £2, with no local existential variables. 

Consequently, the introduction of applicative functors does not require any significant 
change to our definition of semantic signatures — our existing notion of abstract signature 
S already subsumes the kind of quantification that expresses an applicative functor! We 
merely extend functor signatures with a simple effect annotation. As defined in Figure 25, 
an effect <p can either be pure (P) or impure (I). These form a trivial two-point lattice with 
P < I, and there is a straightforward definition of join (V) on effect annotations (we won't 
need meet). To encode effect annotations in our F ffl representation of functors, we assume 
that there are two distinct record labels / P and lj. 

The important point, though, is that a pure functor type may only have a concrete result 
signature E, which is why we give it as a separate production in the syntax of E in Figure 25. 
Nevertheless, we will often write Va.E — > ?) S to range over both kinds of functor signature, 
implicitly understanding that S has to be a concrete E' when <p = P. 

Signature elaboration Figure 26 shows the new elaboration rules for dealing with functor 
signatures (we have highlighted the differences from the original rules from Figure 11). 
The rule S-FUNCT-I for impure functor signatures leaves the original rule S-FUNCT almost 
unchanged, except for adding the effect annotation I on the signature in the conclusion. 

In order to match the description of applicative functor signatures we just gave, the new 
rule S-FUNCT-P for applicative functors must produce a signature where all existential 
quantifiers are "lifted" out of the functor type. It does so by replacing the original a% in- 
ferred for the result signature with fresh a' 2 that are quantified outside the functor signature. 
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(effects) 

(concrete signatures) 



<p V <p 
I V P 



(types) 
(expressions) 



::= I [P 
::= Vce.Z- 

Notation: 



:= <p 

:= PVI := 
Abbreviations: 



Tl — T 2 
A(j,x:T.e 



>i S I Vce.Z -> P E I 



Ti -> {/ 9 : T 2 } 
Ajc:t. {Zip = e} 
(e\ ez).l v 



Fig. 25. Semantic signatures for applicative functors 



Signatures 



n-Si-~»3ai.£i 



r,ai,X:£ir-S 2 ~»3a2-E2 



rh (Z:5i) -> S 2 Vffii.Zi -h 3a 2 .£ 2 



S-FUNCT-I 



r,Bi,X^ir-5 2 -»3S 2 .22 



ri-s~>:E 



rh (X:Si) =>5 2 ^ 3a' 2 .Vai.Ei -»p Z 2 [a 2 a!/a 2 ] 



S-FUNCT-P 



Subtyping 

r,a'hS'<3a.EtT- 



r h s < s' ~» / 



•/i r,a'hE[T/a]<E'-^/ 2 



<P<<P 



Th (Va.E^ 9 S) < (Va'.E'- 



- If: (Va.L^ f Z).Xa'. Xfx-H . h if f (/1 *) ) ? 



U-FUNCT 



Subeffects 



F-REFL 



F-SUB 



(p <(p' 



(p<<p P < I 

Fig. 26. New rules for applicative functor signatures 

But abstract types defined inside a functor might have functional dependencies on the 
functor's parameters. The trick, discovered by Biswas (1995) and Russo (1998), is to 
capture such potential dependencies by skolemizing the lifted variables over the universally 
quantified types from the functor's parameter. That is, we raise the kind of each of the a' 2 
so as to generalize it over all the type parameters lX\\ correspondingly, all occurrences 
of an a £ a 2 are substituted by the application of the corresponding a' £ ot 2 to tne actual 
parameter vector a\ . (At this point, clearly, we require not just System F, but the full power 
of F<b, to model our semantics.) 

To better understand what's going on here, let us revisit the signature of the Set functor 
(cf. Figure 12), and its elaboration into a semantic signature. Figure 27 shows how the anal- 
ogous applicative functor signature will be represented semantically. The new elaboration 
rule places the existential quantifier for /3 outside the functor, and it raises the original kind 
£2 of /3 to £2 — > £1, in order to reflect the functional dependency on a. Everywhere we 
originally had a j3, we now find /3 a in the result. 
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(Elem : ORD) (SET where type t = Elem.t) 

•w 3j3:(G-»n). 

Va:£L{t: [=a:£2], 

eq : [a x a — > bool], 
less : [a x a — > bool]} 
->p {set : [= J3 a : £2], 
elem : [= a : £2], 
empty : [/3 a], 
add : [a x j3a j3a], 
mem : [a x /3 a — > bool]} 

Fig. 27. Example: applicative signature elaboration 

Where such a functor is later applied, j3 remains as is; only a gets substituted by the 
concrete argument type. If that is, say, int, then the resulting structure signature will equate 
the type set to j3int. Any further application of the functor to arguments with a type 
component t = int will yield the same type set = j8 int. 

Subtyping Because the definition of semantic signatures barely changed, only a minor 
extension is required to define functor subtyping, namely to allow pure functor types to 
be subtypes of impure ones. We do not need to change the definition of matching at all. 
Abstract types lifted from a functor body act as if they were abstract type constructors 
defined outside the functor, and the original matching rule (cf. Figure 13) handles them 
just fine. (However, an algorithmic implementation of the rules will require non-trivial 
extensions to the type lookup algorithm, as we will discuss in Section 9.2.) 

In other words, the correct subtyping relation between applicative and generative functor 
signatures falls out almost for free. The F-ing method provides an immediate explanation 
of such subtyping and why it is sound. 

Modules The rule M-SEAL defined in Section 4, when used with an applicative functor 
signature, allows one to introduce applicative functor types. But the circumstances are 
limited: the definition of matching requires that the sealed functor may not itself contain 
any non-trivial sealing, because a functor creating abstract types would be considered 
generative, i.e., impure, under the module elaboration rules from Section 4. Shao's sys- 
tem (Shao, 1999), which introduces applicative functor signatures solely through sealing, 
suffers from this limitation, a point we return to in Section 11. In contrast, the system we 
will present is designed to support sealing within applicative functors, a feature shared by 
all other accounts besides Shao's. That requires refining our module elaboration rules. 

While signatures for applicative functors are (relatively) easy to elaborate, modules 
require more extensive changes to their elaboration rules to account for applicativity and 
purity. Superficially, the only extension to the module elaboration judgment is the inclusion 
of an effect annotation <p, which specifies whether the module is deemed pure or not. 
However, the invariants associated with pure and impure module elaboration are quite 
different from each other, as we explain below. Figure 29 gives the modified rules (we 
have again highlighted the changes relative to the original rules, cf. Figure 14). 
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(kinds) 



(.)-►* 

(T,a) -> k 
(r,x:-r) -» k 


= r-> K a - 
= t^k 


X(-).t> 

A(r,a).-r' 

A(r,x:r).T' 


= t' 

= XT.Xa.-c 
= XT. if 


*'(•) 

r'(r,a) 
t' (r,x:-r) 


= t' 
= rTa 
= tT 



(types) V(-).t' 

V(r,a).-r' 

V(r,XT).T' 

(expressions) A(-).e 

A(r,a).e 
A(r,x:T).e 

*(•) 
e(r,a) 
e {T,x:x) 



vr.va.x' 
vr.-r^p t' 

e 

XT.Xa.e 
Ar.Apx:T.e 

e 

eT a 
(e Tx)p 



r 1 := • 
r p := r 

Fig. 28. Environment abstraction 

Functors We begin by explaining how we handle functors, since this motivates the form 
and associated invariants of the module elaboration judgment. We now have two rules: 
M-FUNCT-I, which yields a generative functor (as before) if the body M is impure, and 
M-FUNCT-P, which yields an applicative functor if M is pure. In both cases, the functor 
expression itself is pure, because it is a value form that suspends any effects of M. 

For applicative functors, we need to follow what we did for signatures, and implement 
3-lifting. The difficulty, though, is doing it in a way that still allows a compositional 
translation of sealing inside an applicative functor. 

What is the problem? Consider the following example: 

fun (X : {type t}) {type u = X.t x X.t}:>{type u} 

If the body of this functor were impure (like the body of Flip from Figure 23), the impure 
functor rule M-FUNCT-I would delegate translation of the functor body to a subderivation, 
which, in this example, would yield a signature E = 3j3. {u : [= j3 : CI]} and some term 
e : E. We would then A -abstract e over the functor argument to produce a function of type 
Voc.{t : [= a : CI]} — ^ E. Now, if we wanted to adapt this situation for pure functors by 
applying the same lifting trick we used for pure functor signatures, then we would have 
to somehow take e : E and retroactively lift its hidden type components over a to derive a 
term of type 3j3' : CI -> Cl.Va : Cl.{t : [= a : CI]} {u : [= fi'a : CI}}. In general, such 
retroactive lifting is not possible. 

To avoid this dilemma, we employ a different trick: we design the translation of a pure 
module (which the body of an applicative functor must be) so that it consistently constructs 
an existential package with the necessary lifting already built in! 

In fact, for simplicity, the translation of a pure module abstracts over the entire environ- 
ment r. More precisely, whereas the impure judgment F\- M :j 3a.L e guarantees that 
The: 3a.E, the pure judgment F h M : P 3a. E e instead guarantees that e is a closed 
term satisfying -he: 3a.Vr.E, where the notation VT.E is defined in Figure 28. This idea 
is borrowed from Shan (2004), who used a similar approach for a translation of the module 
calculus of Dreyer et al. (2003) into System F ra . 

The pure functor rule M-FUNCT-P then becomes fairly trivial: it just computes the 
translation of its body and returns that directly. This means the translation of the functor 
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Modules 



r(X)=L n-S:„S-^e 

M-VAR — — Y „ M-STRUCT 



M-DOT 



T\-X : P Iw XY.X F\- {B} -.yZ^ e 

ri-M: 9 3a.{/ x :T,,T7T/}^e 
rh M.X : 9 3ce.£ ~» unpack (a, v) = e in pack (a, AFP. (y F?)./ x ) 

rhS~>3a.£ r.a,X:ZhM:i S ~> e 
M-FUNCT-I 

r h fun X:S^M : P Va.E ^S-* Ar.Aa.AiX:£.e 
ri-5-+3a.S r.a.X:ZI-M:p3%E2^e 

- — — M-FUNCT-P 

T h fun X:S^-M : P 3a 2 .Va.E -^ P Z 2 ~*e 

r(i 1 ) = v«.£i r(x 2 ) = z 2 rh£ 2 <3a.£i |t^/ App 

n-ZiZ 2 : ? H[T/a]--»Ar i » , .(z 1 T(/Z2)) 9 1 API> 



r(Z)=S' ri-5-+3a.S rhE'<3aXt?-t/ ic a , =r^K„ 

_5 I = ■' _ 1 M-SEAL 

n-X:>5: P 3a'.E[a'r/a] ~> pack (Ar.T, Ar./X) 

r h S ~> S r h E : norm(S) -^ e 

M-UNPACK 

r h unpack E:S :i norm(S) •w e 



Bindings 



r h val X=£ : P {l x : [t]} ~» AF{/ Z = [e]} " VAL 

rh r : K--w % 

B-TYP 

rh typeX=T : P {l x : [= t : k}} ~* AF{/ X = [t : if]} 

T\- M \m 3a.Z e £ not atomic 
rh module X=M: lp 3a.{l x ■ £} **♦ unpack (ee,*) =ein pack (a, AFP.fc =^T^}) 

rh5->E 



ri-B^s-^, 



B-MOD 



T h signature X=S : P {fe : [= S]} ~» XT.{l x = [S]} 



B-SIG 



rhM:,p3a.{Z x :Z}^ e 

B-INCL — ^ . - „ B-EMT 



Th include M: 9 3S.{Z x :£}^e r h £ : P {} ~» AF{} 



rhflt : 9l 3a 1 .{ l Xl :Z 1 }^ei l' Xi = fc , - h 2 

r, a x ,X X :£i h B 2 |g 3a 2 .{/ X2 : E 2 } ^ e 2 ^ : C fr, : £j 

rh5!;fi 2 r^v^ 3a 1 5 2 .{/ Xi :Ej,/x 2 : E 2 } 
unpack (cti , >'i ) = e\ in 

unpack (a 2 ,;y 2 ) = (let = Af^V^^j FJ>i)./ Xl in e 2 ) in 
pack {ai&2, Ar«" v ^.letXi = (yi T<f").l Xl in 



B-SEQ 



letX 2 = (>2 (T,Wi,Xi:E 1 )ft).Z^ in {/^ = X,,/x 2 = X 2 }> 
Fig. 29. New rules for applicative functors and modules 
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Paths 



rhP:E- 



P-MOD 

rhP:Z-w unpack (a,x) =e\nxrf 



T\-E: x~*t 



E-PACK 



Expressions 

rhM: 9 3a.L~^e ThS^Z r h 3a.Z < norm(S) ~~» / 
r h pack M:5 : norm(E) •** / (unpack (a,x) = e in pack (a,jcrP)) 

Fig. 30. New rules for applicative paths and packages 

will not only abstract over the functor's parameters as required, but over the rest of the 
current environment F, too (because 3a2-V(T, a,X:T.).T.2 is just an alternative way of 
writing Bcea-VT.Vcf.E — >p £2). But that is fine, because the functor is itself a pure module, 
so according to the elaboration invariant for pure modules, it has to abstract over F anyway. 

It turns out that the rule M-APP for functor application can remain largely unchanged — 
it can handle both kinds of functors. In both cases, the effect <p on the functor's type is 
unleashed and determines the effect of the application. Note that applicative application is 
always degenerate, with E being some concrete signature £3, so that there are no existential 
quantifiers in the result to lift over. 

Pure modules and bindings The real "heavy lifting" (so to speak) happens in M-seal. 
It abstracts the witness types T over all type variables from F, thereby lifting their kinds 
in a manner similar to what happens in the elaboration of applicative functor signatures 
(except that F generally contains more than just the functor's parameters). Similarly, the 
rule abstracts the term component over all of F, thereby constructing the desired functor 
representation inside the package. Both these abstractions together cause the rule to yield 
a lifted existential type, as desired for an applicative functor. 

But using a different elaboration invariant for pure modules has implications on the 
translation of other module constructs as well. In all places where the original, impure 
rules had to unpack and re-pack existential packages in the translated term, the pure ones 
also have to apply and re-abstract F (rules M-DOT, B-MOD, and B-SEQ). To avoid the need 
for a separate set of rules for pure and impure elaboration, we use the notation defined 
in Figure 28 to make these steps conditional on the effect (p. Rules that return concrete 
signatures do not need to shuffle around F, but simply insert the expected abstraction (rules 
M-VAR, M-FUNCT-I, M-APP, B-VAL, B-TYP, B-SIG, B-EMT). Rule B-SEQ on the other 
hand is somewhat trickier, because it has to handle all possible combinations of effects 
<j?i and q>2- (The let-expression around <?2 in this rule is actually redundant when q>2 — 
P — because e2 is a closed expression in that case — but we leave it alone for the sake of 
simplicity of the rule.) 

Interestingly, sealing is always pure according to the rules. That is because the syntax of 
our module language only permits sealing of module variables, which are values. When 
expanding the derived syntax for M :> S (Figure 2), however, for an M that is impure, the 
overall expression will be regarded impure as advertised, thanks to the rules M-DOT and 
B-SEQ that are needed to type the expansion. 
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Rule M-UNPACK is the only source of unconditional impurity. First of all, an unpacked 
expression must be considered impure if the expression being unpacked might compute to 
package values with different type components (as in the body of Flip). But second, even if 
the expression being unpacked is already a value, it is not possible to treat its unpacking as 
a pure module expression because doing so would require us to be able to somehow project 
out its type components as type-level expressions. (This is necessary if we want to be able 
to lift the type components of the unpack over the context F.) If we were interpreting ML 
modules into a dependent type theory, this might be possible; however, as discussed in 
Section 7.1, given that we are interpreting into F ffl , with packaged modules represented 
as existentials, there is no way to project out their abstract type components as type-level 
expressions, so we treat all unpacked expressions as impure. 

Figure 3 1 shows the translation of the Set functor as an applicative functor according to 
our rules. Compared to the elaboration previously given in Figure 15, the main difference 
is that packing and A -abstractions have switched order, and that the existential witness 
type has been abstracted over a accordingly. Moreover, the nested local let-bindings in 
the sequence rule have been replaced by applications of the functor parameters inside 
the abstraction. As before, the translation produces many administrative redexes that can 
be optimized via some fairly obvious partial evaluation scheme. Figure 32 shows the 
translated Set functor after eliminating all intermediate structures and functors this way, 
for easier comparison with the analogous generative implementation in Figure 16. 

Obviously, always abstracting over F in its entirety, as our rules do for pure modules, also 
leads to over-abstraction (although that is not visible in the example, where we assume the 
initial F to be empty). In particular, it would be sufficient to abstract only over the part of F 
that is bound by, or local to, the outermost applicative functor surrounding a pure module, if 
any. However, semantically the difference does not matter much. It is not difficult to refine 
the translation so that it avoids redundant abstractions, but the bureaucracy for tracking 
the necessary extra information would unnecessarily clutter the rules, so for presentational 
purposes we chose the simpler path. A real-world implementation can easily optimize the 
redundant abstractions by what amounts to (fairly straightforward) local partial reductions. 
We would also expect an implementation to present types in a more readable way to the 
user (e.g., as module paths), but such concerns are outside the scope of this article. 

Paths and packages Finally, Figure 30 shows the modified rules for paths and packages. 
They should not reveal any surprises at this point, because all that changes is the insertion 
of the right r-abstraction/application necessary to match the module rules. 

Importantly, the path rule now fully supports functor applications in type paths. For 
example, the type expression (Set lntOrd).set is well-formed when Set is an appropriate 
applicative functor. This is simply a consequence of our semantic treatment of paths: when 
Set is bound to a functor with the signature given in Figure 27, its outer 3j3 is separated 
in the environment (according to rule B-SEQ) and the module (Set lntOrd).set simply has 
the atomic signature [= j8 int : Q]. Since this signature contains no existentials, it is trivially 
a legal path. 

Contrast that to the behavior under a generative signature for Set, like the one originally 
given in Figure 12. Under that typing, (Set lntOrd).set has the type 3)3 . [— j3 : £2], with a 
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Set ~» 

pack (Aa.lista, 

Xa.XpElem : {t : [= a : CI], 

eq : [a x a — > bool], 
less : [a x a -> bool]}. 
/((letyi = Xa.XpElem : {.. .}.{elem = [a : CI]} in 
let y 2 = 

let >21 = ( let elem = ■■■ in Xa.XpElem : {. . .}.{set = [list a : CI]}) in 
let y 22 = 

in Xa.XpElem :{•••}. 

let elem = (y\ a £/em) P .elem in 
let set = ((>'2 a Elem)p e/em)p.set in 
let empty = ((v2 a Elem)p elem)p. empty in 
let add = ((>'2 0t Elem)p elem)p.add in 
let mem = ((y2 0! Elemjp elemjp.mem in 

{elem = e/em, set = sef, empty = empty, add = add, mem = mem} 
) a Elem)p 

}3j3:(a->£i).Va.{t:[=a:n],...}->p{set:[=/3a:£l], elem:[=a:£2], empty:[/Ja], add:[...], mem:[...]} 
Fig. 31. Example: applicative functor elaboration 

Set ~^ 

pack (Aa.lista, 

Xa.XpElem : {t : [= a : ft], 

eq : [a x a — > bool], 
less : [a x a -> bool]}. 
/(let e/em = [a : il] in 
letsef = [list a : CI] in 
let empty = [nil] in 

let adi = [. . .Elem.eq . . . Elem.\ess . . .] in 
let mem = [. . .Elem.eq . . .Elem.\ess . . .] in 

{elem = elem, set = set, empty = empty, add = acid, mem = mem}) 
)3/3:(Q->r>).Va.{t:[=a:n],...}->p{set:[=/3a:n], elem:[=a:P_], empty:[/3a], add:[...], mem:[...]} 
Fig. 32. Example: applicative functor elaboration, simplified 

fresh local j3 that prevents it from type-checking as a path in rule P-MOD. The same applies 
to any other path to an abstract type defined inside a generative functor. 

Our semantics does, however, allow functor paths with applications of generative func- 
tors if they do not refer to such abstract types. For example, (Set Int0rd).elem yields sig- 
nature 3/3. [= int : CI], which can be used as a path — even in the basic system of Section 4! 
In the extended system presented in this section, we could easily rule out such corner cases 
by requiring P to be a pure module in rule P-MOD, but there is no real reason to do so. 

8 Abstraction safety, dynamic purity, and sharing 

The elaboration rules for applicative functors that we presented in the previous section are 
type-safe in the basic syntactic sense that they produce well-typed terms and types, 
but they are not abstraction-safe. By "abstraction safety", we are referring to the ability 
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signature NAME = { 
type name 

val new : unit — > name 

val equal : name x name — > bool 

} 

module Name = fun X : {} => { 
type name = int 
val counter = refO 

val new() = (counter := Icounter + 1; Icounter) 
val equal (x, y) = (x = y) 
} :> NAME 

module Empty = {} 

module Namei = Name Empty 

module Name2 = Name Empty 

Fig. 33. Problems with abstraction safety in applicative functors: dynamic impurity 

to impose local representation invariants on the abstract types defined by a sealed module 
expression, and to reason locally about the implementation of the sealed module under the 
assumption that all enclosing program contexts will preserve the imposed invariants. 9 

The failure to provide abstraction safety is not a peculiar fault of our semantics: contrary 
to popular belief, none of the existing accounts of applicative functors in the literature 
(or in ML compilers) provide abstraction safety either (Harper et al., 1990; Leroy, 1995; 
Russo, 1998; Shao, 1999; Dreyer et al, 2003). The reason, in short, is that tracking only 
static purity of module expressions — as we have done in the previous section, and as 
other approaches have done before us — is not sufficient: it is important for the purpose 
of abstraction safety to track dynamic purity as well. In a similar vein, it is not sufficient 
to consider only static module equivalence — i.e., the equivalence of type components — to 
decide the equivalence of types resulting from pure functor applications: we also need to 
consider dynamic module equivalence, i.e., the equivalence of value components, as well. 

To see what the issue with abstraction safety is, let us turn to the illustrative set of 
examples in Figures 33 and 34 The first example, concerning the functor Name and its 
instantiations Namei and Name2, demonstrates why we may want to require a functor that 
is statically pure, but not dynamically pure, to be treated as generative. The remaining ex- 
amples, concerning various applications of the Set functor, show how ensuring abstraction 
safety can even be quite tricky when working with a functor that is dynamically pure, as 
long as we do not track dynamic module equivalence. 

9 The term "abstraction-safe" (or "abstraction-secure") has appeared in the literature a number of 
times, but as far as we know without a clear formal definition. The informal description we have 
given here matches the use of the term in various papers by Sewell et al. (Leifer et al. , 2003; Sewell 
et al. , 2007). To make this precise, we would need to build a parametric model of the language and 
use it to establish interesting invariants for abstract data types. This is clearly beyond the scope of 
the present article and would in fact constitute new research, since as far as we know no one has yet 
attempted to build parametric models for fully-Hedged ML-style modules. If anything, though, our 
F-ing semantics may help point the way forward in this regard, since we show how to understand 
modules in terms of System F ffl , for which parametric models do exist {e.g., Atkey (2012)). 
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module IntOrd = {type t = int; val eq = Int.eq; val less = Int. less} 
module IntOrd' = IntOrd 
module Seto = Set IntOrd 
module Seti = Set IntOrd' 

module Set2 = Set {type t = int; val eq = Int.eq; val less = Int. less} 
module Set3 = Set {type t = int; val eq = Int.eq; val less = Int. greater} 

module F = fun X : {} =>■ 

{type t = int; val eq = Int.eq; 
val less = if random() then Int. less else Int. greater} 
module Set4 = Set(F Empty) 
module Set5 = Set(F Empty) 

Fig. 34. Problems with abstraction safety in applicative functors: dynamic module inequivalence 

First, consider the functor Name, which implements an ADT of fresh names. Every time 
Name is instantiated, it will return a module with its own abstract type name, along with its 
own private integer counter (of type ref int) — initially set to 0 — which can be incremented 
to generate a fresh value of type name every time its new operation is invoked. In order 
to ensure that new produces a fresh name every time it is applied, it is crucial that each 
instantiation of Name has a distinct name type — i.e., that we treat Name as a generative 
functor. Otherwise, calling Namei.new might produce a name that Name2.new had already 
produced. 10 However, since Name does not involve any uses of unpacking — i.e., it is 
statically pure — our semantics from Section 7 would consider it to be applicative, as would 
OCaml (since in OCaml all functors are applicative) and Moscow ML (in which, even 
if Name were declared as generative, it could be subsequently coerced to an applicative 
signature by eta-expansion, thus violating abstraction safety). In the case of our semantics 
from Section 7, one could induce Name to be considered generative by replacing the 
sealing in its body with a pack at NAME followed by an unpack, but this is a rather indirect 
approach, and it does not work in OCaml or Moscow ML due to their restrictions on the 
use of the unpack construct. 

Second, consider the set types defined by modules Seto through Sets in Figure 34. 
Seto. set, Seti.set, and Set2.set should clearly be equivalent, since they are constructed 
by passing Set the exact same argument IntOrd, just written three different ways. 

To ensure abstraction safety, however, Set3.set should be considered distinct from the 
others: the argument passed to Set in the definition of Set3 provides a different ordering 
on integers (Int. greater), thus rendering the representation of Set3.set incompatible with 
the representation of sets ordered by Int. less. If we were to treat Set2.set and Set3.set 
as equivalent, the definition val s = Set2.add(l, Set3.add(2, Set2.add(3, Set2. empty))) 
would become well-typed. That would be disastrous, because it would yield a set value rep- 
resented internally by the list [1,3,2], which violates the internal ordering invariants of both 

10 One can, of course, engender use-site generativity by explicitly sealing each application of Name 
with the signature NAME. However, this is no substitute for true abstraction safety, since it 
demands disciplined use of sealing on the part of clients of the Name functor — it does not ensure 
that any local invariants on the abstract name type will be preserved under linking with arbitrary 
clients. For a more detailed semantic explanation of the importance of generativity in this example, 
see Ahmed, Dreyer & Rossberg (2009). 
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Set2 and Set3's list-based set representations. This would result in unpredictable behavior 
from any further interactions with Set2 and Set3's operations; for instance, Set2.mem(2, s) 
and Set3.mem(2, s) would both return false! 

As for Setzj.set and Set 5 .set, it is important to distinguish them from each other (and 
from all the other set types): depending on the result of a random coin flip, either/both of 
these types could end up being compatible with either/both of Set 2 .set and Set 3 .set, but 
statically we have no way of knowing. We must therefore conservatively insist that they 
are both fresh types, even though they are defined using the exact same module expression 
Set(F Empty). 

Getting abstraction-safe applicative behavior on these Set examples seems to be hard, as 
indeed all previous accounts of applicative functors are unsafe and/or overly conservative 
in one way or another. Assuming that the Set functor has been assigned an applicative 
signature, the type system of Section 7, as well as those of Moscow ML, Shao (1999), and 
Dreyer et al. (2003), all consider Seto through Sets to have equivalent set components. 
The reason is that they employ a "static" notion of module equivalence, meaning that 
they consider the type components of Set(Mi) and Set(M2) to be equivalent so long 
as Mi and M2 have equivalent type components. As one can plainly see, though, this 
approach is demonstrably unsafe: since sets ordered one way are not compatible with sets 
ordered a different way, the semantics of the type component set in the body of the Set 
functor clearly depends on the value component less of the functor argument. In contrast, 
OCaml only considers Set(Mi) and Set(M2) to be equivalent if Mi = M2 syntactically. 
However, this is quite restrictive, with the consequence that Seto. set, Seti .set, and Set2.set 
are all considered distinct for no good reason. Moreover, OCaml deems Setzt.set and 
Sets.set equivalent just because they are constructed from syntactically identical module 
expressions, even though doing so constitutes a clear violation of abstraction safety. 

8.1 Elaboration 

In this section, we refine our elaboration from Section 7 in order to arrive at a semantics 
that achieves abstraction safety in a satisfactory manner. 11 Our approach is as follows. 

First, in order to deal with examples like the Name functor, which ought not to be 
applicative, we now take into account not only static purity, but also dynamic purity. That 
is, in the elaboration of pure modules, we only permit value bindings that we can prove 
to have no side effects. The intuition behind this restriction is simple: if a module defines 
abstract types and also has computational effects, then it is only safe to assume that the 
semantic meanings of the abstract types are tied up with the effects. For example, the 
meaning of the name type in the Name functor is semantically tied to the stateful counter — 
in particular, it represents the set of natural numbers less than the current value of counter 
(which may only grow over time). 

11 As explained in footnote 9, the notion of abstraction safety is somewhat informal. The claim 
that the semantics described in this section regains abstraction safety is likewise informal, and to 
justify it formally would take us beyond the scope of this article. At the very least, we believe it is 
clear that our semantics does not suffer from the same problems with abstraction safety that afflict 
previous approaches. 
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E 
P 
M 
B 



... | P | packM:5 

M 

X | {B} | M.X | fun X:S^M\ X:>S 

\ia\X=E | typeX=T | module X=M | signature X=S | include M | e | B;B 



Fig. 35. Non-expansive expressions 



(paths) k 
(concrete signatures) £ 



[=n:x]\ ... 



Abbreviations: 



(types) [= jr : t] := {val : t, nam : 7l} 

(expressions) [ease'] := {val = e,nam = e'} 

Fig. 36. Semantic signatures for tracking sharing 



Second, we observe that it is only abstraction-safe to equate the types returned by 
applicative functors if the arguments passed to them are dynamically (as well as statically) 
equivalent. This explains why Seto, Set;, and Set2 produce equivalent set types, but they 
are distinct from Set3 .set. In order to check for dynamic equivalence of functor arguments, 
we thus refine our semantics to (conservatively) track the "identity" of values. 

Dynamic purity Determining whether an expression is dynamically pure is undecidable. 
As a conservative approximation, we piggyback on a notion that already exists in ML: the 
syntactic classification of non-expansive expressions — essentially, syntactic values. In ML, 
this notion is used in the core language to prevent unsound implicit polymorphism, the so- 
called value restriction (Wright, 1995). It makes perfect sense to reuse it here, because an 
applicative functor can be thought of as a polymorphic function on steroids. 

Figure 35 gives a suitable grammar for non-expansive expressions E that accounts for 
paths and packages. The ". . . " in the grammar for E will typically define a sub-language of 
what is templated as ". . . " in the grammar for E (cf. Figure 1), but the specifics obviously 
depend on the concrete core language. For module expressions M contained in E, the only 
constructs disallowed are functor application and unpacking. 

Depending on the details of the core language and its type system, more refined strategies 
are possible for classifying pure value bindings. Fortunately, this does not affect anything 
else in our development, so we stick with the simple notion of non-expansiveness for 
simplicity; adopting something more sophisticated should be straightforward. 

Dynamic module equivalence and semantic paths We have demonstrated above that 
abstraction safety requires type equivalence to take dynamic module equivalence into ac- 
count. As we have mentioned already, our approach relies on the tracking of "identities" 
for value components of modules. Since equivalence of values is obviously undecidable in 
general, we again use a conservative approximation: our new typing rules employ "phan- 
tom types" to identify values, i.e., abstract type expressions that we call semantic paths 
n. Usually, such a path is just a type variable, but due to the lifting that happens with 
applicative functors, it can actually take the more general form defined in Figure 36. 
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r\-D^z 



n-r:f2-+-r Ka = n 

r\-va\X:T ~>3a.{l x : [= a : t]} 



D-VAL 



Subtyping 



r h s < s' ~> / 



7T = ^ n-t<T'*»/ 



ri- [= % : t] < [= 7t' : t'] -*> Xx:[= n : t].\f(x.va\) asx.nar 



U-VAL 



Bindings 



ThB: 9 E 



B-VAL-I 



rh£:T-^e Ka=Q, VE. £ / E \JP.E^P 
T h val *=£ : z 3a.{/ x : j= a : t]} - pack {{}, {Z x = [e as {}]}) 

r h E : T ~> e k-„ = T £2 VP. E/P 
rh valX=E: P 3a. {/ x : [= aT : t}} pack <Ar.{}, Ar.{/ X = [eas{}]}) 

ri-P: f ,3a.[=jr:'F]«~e 
r h val X=P :,p 3a. {lx : [= ft : t]} — > unpack (a,x) = e in pack (a, XTf .{lx =*}) 



B-VAL-P 



B-VAL-ALIAS 



Expressions 



n-P:q,3a.[=jr:T]~»e rhT:£2 
rhf: unpack (a,x) = e in (x TP). val 

Fig. 37. Elaboration of value sharing 



E-PATH 



Paths are recorded in an extended definition of atomic value signature, also given in 
Figure 36. Consequently, every value binding or declaration will be associated with a 
semantic path. As with abstract types, we can quantify over path variables (existentially 
and universally), and thus abstract over value identities. 

Semantic paths can be viewed as a refinement of the concept of structure stamps, which 
tracked structure identity in SML'90 (Milner et ai, 1990). Here, we reinterpret the ad hoc 
operational notion of "stamp" as a phantom type introduced via System F quantification, 
and we use it to stamp individual values rather than whole structures, thus enabling the 
tracking of identities at a finer granularity. (We could reconstruct "real" structure stamps, 
essentially by tracking module identities in addition to value identities. But in the presence 
of fine-grained value paths we see no additional benefit in also having structure stamps.) 

Obviously, our notion of semantic paths could be refined in various ways. For example, 
certain values, such as scalar constants, could be captured more precisely by reflecting them 
on the type level (equating more values and hence allowing more programs to type-check). 
However, such details are beyond the scope of this article. 
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Elaboration The new and modified rules for value declarations and bindings are shown 
in Figure 37. We once more have highlighted the relevant changes. 

For a value declaration (rule D-VAL), we always introduce a fresh path variable (of 
kind Q.) as a place-holder for the actual value's identity. For value bindings, there are now 
three rules. If the binding just rebinds a suitable path P, then we actually know the value's 
identity, and can retain it (rule B-VAL- ALIAS). Otherwise, we treat the value as "new" and 
introduce a fresh path variable representing it; the witness type for the variable does not 
matter, so we simply pick {}. The binding can be treated as pure if the expression is non- 
expansive (rule B-VAL-P), in which case we have to abstract over T inside the package, in 
the same way we did in the sealing rule M-SEAL (Figure 29). 

Subtyping requires atomic value signatures to have matching paths (rule U-VAL). For 
now, this condition is trivial to meet, because a rule D-VAL always produces a sepa- 
rate, existentially quantified path for every single value declaration, so that the matching 
rule U-MATCH can pick them freely before descending into the subtyping check. In Sec- 
tion 8.2 below, we present another small language extension that makes the condition more 
interesting, though. 

Finally, in the premise of the modified rule E-PATH, P is elaborated as a full module. 
This is more permissive than going through the generic path rule P-MOD as before (cf. 
Figure 30), because the new rule also allows dropping any quantified variable that only 
occurs in the path %. Without the modified rule, our encoding of let -expressions would 
no longer work, since every local value definition (that is not a mere alias) introduces 
an existential quantifier as its path. (Consider let val x = 1 in x+x, which desugars into 
{val x = 1; val it = x+x}. it — as a module, its type is 3aiOC2-[= &2 ■ int], so that at 
cannot be avoided by the path rule P-MOD. Rule E-PATH, on the other hand, can drop 
both variables.) 

Example Figure 38 shows the result of elaborating the (applicative) functor signature 
describing Set, previously shown in Figure 27, under the updated rules. Differences to the 
previous result are highlighted: atomic value signatures now carry path information, the 
signature abstracts the path variables ct\, OL2 and j3i to j33, and the export type j3 has to be 
applied not just to the argument type a but also to the argument paths <X\ , (Xi, accordingly. 

Given a Set functor with the semantic signature from Figure 38, the types Seto.set, 
Seti .set, and Set2.set (from the beginning of the section) will be seen as equivalent: they all 
elaborate to the semantic type j3 int 7£eq ^| ess , with the two paths 7Teq and n\ ess referring to 
the respective members of structure Int. They are distinguished from type Set3.set, which 
elaborates to j3 int 7C e q ^greater- 
Types Set4.set and Sets. set are also fresh, because the functor F will be deemed impure 
under the new rules, due to its binding for less, which features an expansive application 
(random()). Its semantic signature looks as follows (highlighting the pieces that have been 
added or changed with the refined rules): 

F : {} — >i 3j3i:fl.{t: [= int: £1], 

eq : [= TTeq : int x int — > bool], 
less : [= J3i : int x int — > bool]} 
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(Elem : ORD) => (SET where type elem = Elem.t) 

~* 3j3:(£2 3 ^^),ft:(f2 3 £2), j3 2 :(f2 3 £2), j3 3 :(£2 3 

Va:f2,a 1 :n,a 2 ; ^-{ t : [= « : £2], 

eq : [= ai : a x a -> bool], 
less : [= a 2 : a x a -> bool]} 
— s> P {set : [= j3 a cti a 2 : 
elem : [= a : £i], 

empty : [= ft a a.\ a 2 : ft a a\ a 2 ] , 

add : [= ft a a,\ a 2 : a x j3 a ai a 2 — > p a ay a 2 ] , 

mem : [= ft a a\ a 2 : a x j3 a 0£] a 2 — > bool]} 

(where f2 3 ^ fl := £2 -> fl -> Q. -> Q.) 

Fig. 38. Example: signature elaboration with value tracking 



Hence, F delivers a fresh path for less with every application, and so each application of 
the Set functor to F Empty will produce different set types. 

The Name functor will be considered impure under the new rules as well, because of the 
local effectful binding for counter. Here is its signature according to the refined rules: 

Name : {} -h 3j3:£2,/3i:£2,j3 2 :£2.{name : [= J3 : £2], 

new:[=/5i:{}^j3], 

equal : [= /3 2 : j3 x /3 — >• bool]} 

Consequently, the functor will behave generatively, with Namei.name and Name 2 .name 
elaborating to distinct fresh abstract types. 



8.2 Sharing specifications 

Once value identities matter for determining type equivalences, it can be useful to give 
the programmer the ability to explicitly specify sharing constraints between values. For 
example, consider a functor that takes two arguments, both with a sub-module Ord: 

signature A = {module Ord : ORD; val v : Set(Ord).t; . . . } 
signature B = {module Ord : ORD; val f : Set(Ord).t -> int; . . . } 
module F (X : A) (Y : B) = { . . . Y.f (X.v) . . . } 

Clearly, the application in the functor's body cannot type-check without knowing that 
X.Ord and Y.Ord are statically and dynamically equal. For that, we need to be able to 
impose sufficient constraints on the parameters. 

Figure 39 presents syntax for manifest value specifications (using module paths P) and 
a related signature refinement using where. It also introduces similar forms to specify 
sharing between entire modules, which serves as an abbreviation for sharing all type and 
value components. Finally, we add a construct, "like P", which yields the signature of the 
module P, and thus can only be matched by modules that provide the same definitions as 
P. In essence, this describes a higher-order singleton signature in the manner introduced 
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(signatures) 5 ::= 
(declarations) D ::= 



S where val X=P \ S where module X=P | like P 
va\X=P I module X=P 



Fig. 39. Extension with value and module sharing specifications 



Signatures 



T\-S~* 3aiaa 2 .E rh P : [= n : z'} ~> e 
E.Z^ = [= a : t] r I- t' < t ~» / 
rh 5 where val X=P ~» 3a i a 2 .£[JE/a] 



S-WHERE-VAL 



r I- 5 ^ 3a.E rhfil'^e E.fr = E" 
a = aiWa 2 3a 2 .E" explicit r, a\ h £' < 3a 2 .E" f T ~» / 
T h 5 where module X=P ~^ 3a i .E[T/a 2 ] 

rhP:L"»c E explicit 



S-WHERE-MOD 



S-LIKE 



Declarations 



rhD-» s 



r h P : [= : t] e 
T^va\X=P~^ {I x :[=k:t\} 

r h i 5 : E ~* e E explicit 



D-VAL-EQ 



, D-MOD-EQ 

r h module X=P ~* {lx : E} 
Fig. 40. Elaboration of value and module sharing specifications 

by Dreyer et al. (2003). 12 A manifest specification module X=P is equivalent to the 
specification module X : like P. With these extensions, we can, for example, define the 
functor F properly as follows: 

module F (X : A) (Y : B where module Ord = X.Ord) = { . . . Y.f (X.v) . . . } 

One subtlety to point out here is that the design of these constructs depends on the 
fact that our elaboration is deterministic, and so any path P trivially has a unique type in 
our system. If that weren't the case — e.g., if modules only had principal types — then the 
"where module" and the "like" construct would not yield a unique signature specifica- 
tion, i.e., their meaning would be ambiguous. To compensate, it would be necessary to 
require the programmer to disambiguate those constructs with explicit signature annota- 
tions ":5" on the paths. A deterministic type system avoids any such nuisance. 

Elaboration The respective elaboration rules are shown in Figure 40. Rule S-WHERE-VAL 
is analogous to S-WHERE-TYP (cf. Figure 11). 



It is also very similar to the "module type of" operator that was introduced in recent versions of 
OCaml. The difference is that OCaml's operator does not propagate the identities of abstract types 
defined by the module, which we find rather surprising. 
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Module refinement (rule S -WHERE-MOD) is slightly more involved. It is defined as 
refining every individual abstract value and type specification in submodule X of S. This 
module has the signature L", and the type variables CC2 identify its abstract entities; the 
remaining ~ot\ are used elsewhere in £ and remain untouched. The concrete signature £' 
of the refining path P has to match 37*2 (Typically, 7*2 will coincide with the subset 
of a that are free in L", because only in rare circumstances can matching succeed with an 
unquantified HGCli left over in £". 13 ) 

The rules for manifest value and module declarations are straightforward, as is the rule 
for singletons. 

In all the module forms, a side condition about explicitness is necessary to maintain the 
elaboration invariant that is required for decidability (cf. Section 5.2). Inductively, we only 
know that the respective signatures are valid, but because they can occur on the right-hand 
side of a match, we would lose decidability (which we will prove in Section 9.2) if we did 
not require them to also be explicit. In practice, the signature of a path (or any module, 
for that matter) can always be enforced to be explicit by imposing a signature annotation. 
Alternatively, any "classic" syntactic path consisting only of variables, projection, and pure 
functor application will satisfy the explicitness criterion, as long as those variables in turn 
are bound to definitions with explicit signature annotations. 

In the case of rule S -WHERE-MOD, however, 3a2.£" can only be made explicit (and the 
refinement made well-formed) by ensuring that the signature of the specialized submodule 
is sufficiently self-contained, i.e., none of its type components refers to any of the a,\ from 
the surrounding signature. It is not merely decidability concerns that demand this. For 
example, the refinement in 

signature S = {type t : * — > *; module A : {type u = t int; . . . }} 
module B = {type u = int; . . . } 
signature T = S where module A = B 

would require higher-order unification to find a t such that t int = int. Not only is that 
an undecidable problem in the general case, it also has more than one "solution" for this 
example, and the signature T would therefore have an ambiguous meaning. Consequently, 
the above example is disallowed by the rule — t is not rooted in the inner signature of A, 
although it mentions it. But the example can be disambiguated by splitting the refinement 
into stages: 

signature T = (S where type t = fun a => a) where module A = B 

If all types from the surrounding signature have an alias in the submodule, however, then 
our system accepts the direct refinement: 

signature S = {type t : * — > *; module A : {type u = t; . . . }} 
module B = {type u = fun a => list a; . . . } 
signature T = S where module A = B 

(And because we always j3 tj -normalize all types, this even works when u is specified as 
fun a =>■ t a in signature S.) 

13 With ML as a core language, one such example would be if Z" contained a value component of 
type t int — > t int. This type could be matched by a £' in which the corresponding component had 
type Va.a — > a, which does not mention t but can nonetheless be instantiated to t int — > t int. 
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The "where module" construct has been a rather dark corner of ML-style modules. 
While it is often available in one form or another, its semantics tends to be either vague 
or over-restrictive (or both), and rarely is it properly specified. The structure sharing spec- 
ifications of SML'90 (Milner et al, 1990) were the earliest form of a comparable con- 
struct, but they were both relatively restricted and semantically complicated, resorting 
to global "admissibility" conditions. In SML'97 (Milner et al., 1997), they were hence 
degraded to a form of syntactic sugar, but this is arguably not quite the right thing either, 
since their desugaring in fact relies on type information. As has been observed repeatedly 
by SML implementers, the SML'97 semantics has a severe limitation: it prevents the 
placement of structure sharing constraints on any signatures that export a single transpar- 
ent type specification! Generalizations and improvements, including the complementary 
"where module" (or "where structure") mechanism, have been discussed in online 
forums and implemented in some compilers (e.g., SML/NJ (SML/NJ Development Team, 
1993) and Alice ML (Rossberg et al., 2004)), but have never been formalized as far as 
we are aware. In OCaml, "with module" is superficially similar, but actually extends 
a signature instead of just refining types, which apparently is considered a bug. 14 Our 
elaboration rule S -WHERE-MOD may thus be viewed as a novel step in the right direction. 

9 Meta-theory revisited 

Having made non-trivial extensions to our system in the last two sections, we need to revisit 
the meta-theoretical properties that we proved about the initial system in Section 5. 

9.1 Soundness 

The soundness statement for the new elaboration rules has to cover the elaboration of pure 
modules now. But first a helpful lemma about typing environment abstractions: 

Lemma 9.1 (Typing of environment abstraction) 

LetrhDandr 1 ,r,r 2 i-n. 

1. If and only if Y h T : K, then • h XY.T :Y ->• K. 

2. Ifandonlyifri,r,r 2 l-T:r^K-,thenri,r,r2l-Tr: K. 

3. If and only if Y h T : Q., then • h Vr.T : £1. 

4. If and only if Y h e : x, then • h XY.e : VT.T. 

5. Ifandonlyifr!,r,r 2 he:Vr.T, thenri,r,r 2 her: T. 

6. (XY.t) r = t. 

In the actual soundness statement, pure module elaboration has a somewhat more intri- 
cate invariant than its impure version, as given by part 7 of the following theorem (all other 
parts read as before): 

Theorem 9.2 (Soundness of elaboration with applicative functors) 

Let r ha 



See the bug report at http : //caml . inria.f r/mantis/view.php?id=5514. 
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1. If rh T : K~* T, thenTh t: k. 

2. If rh E : T -w e, then r h T : and T h e : T. 

3. If r h T < t' -w / and T h T : Q. and T h %' : i2, then r h / : T -> t'. 

4. If Th P : E -w e, then r h E : £2 and F h e : E. 

5. IfrhS/D^S, thenTh E : £1 

6. If T h Af/fi : r S-*e, then r h S : £2 and F h e : S. 

7. If r h M/B : P 3a.E ~» e, then T h 3a. E : £2 and • h e : Ba.VT.E. 

8. If T h S < E' -w / and T h S : £2 and T h S' : £2, then r h / : S S'. 

9. If T h E < 3a.E' t T -w / and T h E : D. and T, a h E' : i2, 
then F\-x:K a and T h / : E -> E'[f/a]. 

Proo/ 

By simultaneous induction on the derivations. Most cases are proved as before (Theo- 
rem 5.1), except that some use additional abstraction over F, and we have added a number 
of new rules, most of which are fairly straightforward. We give the two most relevant cases 
for elaborating applicative functors and pure modules: 

• Case M-FUNCT-P: By induction on the first premise we know that F h 3a.E : Q., 
and by iterated inversion this implies (1) F,a h E : Q.. Hence we can show that 
F,a,X:L h □. By induction on the second premise it follows that (2) F,a,X:L h 
3a 2 -^2 : H and (3) T h e : 3a 2 -V(r, a,X:E).E 2 . Statement (3) already proves the 
second goal, because 3a2.V(T, a,X:E).E2 = 3a2-VF.Va.I. ^ P E 2 by the definition 
of environment abstraction. 

To prove the first goal, inverting (2) gives F,a,X:L, a 2 h E 2 : Q., which can be triv- 
ially strenghtened and reordered to F, a 2 , a h E 2 : £1. By weakening (1) to F, a, a 2 h 
E : Q., applying F ffl typing rules, and induction over the length of ai and then a 2 , we 
arrive at F h 3a 2 .Va.E — > P E 2 : il. 

• Case M-SEAL: Since we assume that F is well-formed, the first premise implies (1) 
r h E' : il By induction on the second premise we get F h 3a.E, which can be 
inverted to (2) F, a h E : il By induction (part 9) we can conclude (3) T h T : K a and 
(4)rh/:E'^E[T/a]. 

Consider the first goal first. By Lemma 9. 1 and F m kinding, we get F, a' ha'P: K a , 
and accordingly, F, a' h [a' F/a] : T, a, so that the substitution lemma applied to (2) 
yields T,a' h E[a' T/a] : il By induction over the length of a', F ro typing rules then 
give r h 3a'.E[a' F/a] : Q. as desired. 

For the second goal, first derive (5) F h f X : E[r/a] by simple application of F ra 
typing rules to (1) and (4). Lemma 9.1 then gives • h XF.fX : Vr.E[r/a]. Likewise, 
• h Ar.T : r — > K a follows from (3). The lemma also gives (XF.t) F = T, and hence 
it holds that E[r/a] = E[(Ar.r) F/a] and we can apply the conversion rule and 
Lemma 9.1 to (5) to get • h XF.fX : Vr.EpTVr) F/a]. Since we assume that 
a' are fresh by convention, this is the same type as VT.E[a' F / a][(XF .t) / a'], and 
induction over a' for application of the pack typing rule gives the wanted result. □ 

9.2 Decidability 

Recall from Section 5.2 that the decidability of our type system solely hinged on the 
decidability of subtyping — more specifically, type lookup for the matching rule U-MATCH. 
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This has not changed with any of the extensions we made. In fact, except for the trivial 
incorporation of effect subtyping, the addition of applicative functors did not change the 
declarative subtyping and matching rules at all! 

However, the presence of applicative functors does necessitate fundamental changes to 
their algorithmic implementation. In particular, type lookup now has to look into pure 
functor signatures in order to find suitable types for matching, and the contravariance 
of functor parameters results in a significantly more complex definition of the lookup 
function. That also makes the surrounding definitions and proofs more involved than what 
we have seen so far. (The end of this section has a few remarks concerning this complexity.) 

Validity and rootedness First, we observe that our previous definition of signature valid- 
ity and, specifically, rootedness (cf. Figure 18) is no longer appropriate — it is violated by 
the new rules for pure functors (S-FUNCT-P and M-FUNCT-P), where we lift an existential 
quantifier over a universal one, and thus separate the existential quantifier from the struc- 
ture that roots its variables. To deal with the additional extensions from Section 8, we must 
also account for abstract value paths — however, they are treated like any other abstract 
type variable, so do not affect the definitions and proofs much. (That is, the essential meta- 
theoretical complexity encountered in this section already comes up for the simpler system 
from Section 7 alone.) 

Let us consider a couple of simple examples first. An abstract type ft : £2 is rooted in a 
structure signature {t\. [= ft : £2]} (as before), so that 3j8i .{ti : [= ft : £2]} is a valid (and 
explicit) signature. Likewise, structures can be roots for higher-kinded types, if they specify 
them at their higher kind — for example, ft : £2 — > £2 is rooted in {t 2 : [= ft : £2 — > £2] } (still 
as before). What's new now is that types may also be rooted in a pure functor signature. 
For example, a higher-kinded ft : £2 — > £2 can now be rooted in 

Vai,a 2 .{u: [= a x :£2],v: [= a 2 : £2]} -> P {t 3 : [= ft ai a 2 : £2]} 

if the path j3 a.\ a 2 — with a.\ , a 2 being exactly the list of abstract types that the functor 
quantifiers over — is rooted in the functor's result signature. Consequently, 

3ft.Va l7 a 2 .{u: [= a x :£2],v: [= a 2 : £2]} ^ P {t 3 : [=ftaia 2 :£2]} 

is a valid (and explicit) signature. (As a degenerate case, the universal quantifier in a functor 
signature can actually be empty; such functors can be roots even for abstract types of 
ground kind £2 — e.g., ft is rooted in {} — >- P {1:4: [= ft : £2]}.) 

Figure 41 gives an extended definition of validity and related properties. Rootedness 
takes applicative functors into account: a variable may now be rooted in a pure functor's 
codomain. As a side effect, the definition no longer is concerned with plain type variables 
only, but generalises to semantic paths %. In the functor case, we extend the current path by 
applying the functor's universal variables before descending into the codomain, mirroring 
the kind-raising substitution performed by rule S-FUNCT-P. The path % in the rootedness 
relation is always "abstract", in the sense that it is restricted to the form a a'. We write 
head(^) to denote the head variable a in such a path. 

However, we have to be careful not to treat variable occurrences inside a functor as a 
root when that functor's argument already mentions that variable. For example, the (valid) 
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£ rooted in E always 

a, ce rooted in E :<S> a rooted in E avoiding a, a A a rooted in E 

K rooted in [= n' : t\ avoiding j8 (at e) :<S> n = 7t' 
% rooted in [= T : if] avoiding /3 (at e) n = T 

;r rooted in {/ : E} avoiding /3 (at 1.1) :<S> ;r rooted in {/ : E}.Z avoiding j8 (at 7) 

n rooted in Va.Ei — >p E2 avoiding |3 (at 7) ft ce rooted in E2 avoiding j8 (at 7) A /3 n fv(Ej 

[= 7t : t] explicit (always) 
Va.E — >,p E explicit 3a.E explicit A E explicit 



[= % : t] valid (always) 
Va.E — >,p E valid :<S> Bce.E explicit A E valid 

Fig. 41. Validity for applicative functors 

signature 

Va.{u: [= a : Q],v: [= J3 a : a]} ^ P {t: [= j3 a : a]} 

cannot possibly be a root for j3 , even though the path j3 a has the right form in its codomain. 
Intuitively, with j5 already occurring in its argument, this functor cannot be the origin of the 
abstract type j3 . Rather, it represents a functor signature like (X : {type u; type v = b u}) 
=>■ {type t = b X.u}, where the type b that /3 corresponds to is bound somewhere else. 
(Technically, the refined type lookup algorithm that we are going to define in a moment 
could produce cyclic results if we allowed examples like this as input.) The problem 
extends to multiple variables. Imagine: 

3j3ij3 2 .{F:Va.{t: [=o:fl],u: [= j8 2 : Q. -»• fl]} -h> {v : [= j8, a : Q]}, 
G:Va.{t: [=a:i2],v: [= j8i : Q Q]} ^ P {u : [=j3 2 a:i2]}} 

We cannot allow such a signature to be regarded explicit, because j3i and j3 2 would then 
have a cyclic dependency. 

The new rootedness judgment excludes such cyclic examples, by (1) enforcing that 
each rooted variable is "avoided" by any functor parameter signature its root is under, 
and (2) inductively requiring that for multiple variables, each root not only avoids the 
variable itself, but also any of the following ones, thereby imposing sequential dependen- 
cies. Intuitively, then, the order of the quantified variables has to reflect the order of the 
respective declarations from which they originate. (This means that we are no longer as 
free to reorder quantified variables as we were before. We can only pick an order that 
represents a topological sorting with respect to the (non-cyclic) dependency graph of the 
declarations. Our definition of signature normalization (Section 6) hence is in need of 
refinement. However, the details are not very interesting, so we omit them here.) 

With the new and improved definition of rootedness, the validity lemma is valid again, 
and we can extend it to the pure judgments: 

Lemma 9.3 (Simple properties of validity with applicative functors) 

1. If and only if n rooted in E avoiding j3 1 and % rooted in E avoiding /3 2 , 
then % rooted in E avoiding j3 [ , /3 2 . 
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2. If % rooted in E avoiding j3j and fv(E) Hj3 2 = 0, then n rooted in E avoiding j3 1 ,j3 2 - 

3. If a rooted in E, then a rooted in E[f'/a'], provided an (fv(f') U a') = 0. 

4. If E explicit, then E valid. 

5. If E valid/explicit, then S[t/o~] valid/explicit. 

6. If E valid/explicit, then norm(E) valid/explicit. 

Lemma 9.4 (Signature validity with applicative functors) 
Assume F valid. 

1. If T h P : E e, then E valid. 

2. If T h 5/D E, then E explicit. 

3. If r h M/B :,p E ~» e, then E valid. 

Type Lookup Of course, the more liberal definition of rootedness and signature validity 
now necessitates a more general type lookup algorithm. The upgrade is shown in Figure 42. 
Like rootedness, it now deals with semantic paths % instead of plain variables. That is, it no 
longer just looks for type variables but for paths. When lookup descends into the codomain 
of a functor type, it extends the current path with the functor's parameter variables. These 
parameters become parameters of the looked-up type, matching up with the raised kind 
that an abstract type from an applicative functor is given. 
For example, consider 

lookup^ (Va.{u: [= a : CI]} ->- P {t: [= int : CI]}, 

Va'.{u: [= a' : CI}} -> P {t: [= J3 a' : CI}}) 

which looks for the type j3 : CI -> CI (rooted in the second signature) in the first signature. 
It first takes the variables from the root's universal quantifier (in this case only a single a') 
to extend the path j3 to j3 a'. It then performs lookup for this new path in the functors' 
codomains, yielding type int. Adding the parameters in the end, it returns Xa'.mt as the 
appropriate substitution for j3 itself. 

But that is not enough. In general, a type looked up in the codomain may have occur- 
rences of variables from the left hands universal quantifier, which would escape their scope 
if we left them alone. Consider: 

lookup^ (Va.{u: [= a : Q.]} {t: [= list a : Q]}, 
Va'.{u: [= a' : CI}} ^ P {t: [= J3 a' : CI}}) 

Here, just performing lookup in the codomain would give us list a for j3 a', which is no 
good because the a it contains would be unbound. As with functor subtyping, we hence 
have to substitute a first, in a contravariant fashion. We do so with the corresponding types 
inversely looked up in the right-hand side's domain, i.e., lookup a ({u: [= a' : i2]},{u: [= 
a : CI]}) for the example, and thereby mapping a to a'. As a result, the main lookup will 
return list a' for j3 a' — but that is fine, because we have to lambda-abstract over a' anyway. 
We arrive at Aa'.list a' (or just list, by 77 -equivalence) as a proper substitute for j3. 

Unfortunately, as our earlier discussion of rootedness already suggested, contravariance 
complicates the lookup of multiple variables, because it can create dependencies between 
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lookup e (£,£') 




t e 


always 




lookup aS (£,£') 




t T,T 


if lookup„ (£, E')|t A fv (t) D Ct 
A lookur%(£, £'[*/«]) t t 


= 0 


lookup JI ([= n" : t], 




t 


if 7r' = 7T 




looku P7r ([=-r: k],[= 


= z':k]) 


t T 


if t / = % 




lookn P)[ ({/ :£},{/' 


:£'}) 


t T 


if 3/ e /n/'. lookup„({Z :£}./,{*' 
if lookup ff (E' 1 ,S] ) t t' A head(^r) 
Alooku P?r «,(Z 2 [T7a],Z' 2 )tT 


£'}./) fT 

^fv(t') 


lookup^Va.Si — >p 


Z 2 ,Va'.Z'j 


-+ P £ 2 ) | Aoc'.t 



Fig. 42. Algorithmic type lookup with applicative functors 



the results. Consider: 

S = 3/Jt/fe.E, E = {F : Vo.{t : [= a : £2]} ^ P {t : [= ft a : £2]}, 
G:Va.{t: [= a : £2]} ^ P {t: [=j3 2 a:£2]}} 

S' = Bft'^X', E' = {F : Va'.{t : [= a' : £2]} -> P {t : [= j8{ a' : £2]}, 
G:{t:[=/3(int:£2]}^ P {t:[=$:£2]}} 

If we want to check S < E', then looking up j5[ , j3 2 independently would deliver 

lookup^, (£,£') t Aa'.jSj a' 
looku P/3 ! (£,£') t ft (flint) 

The solution for j3 2 still contains an occurrence of ft', which we need to substitute away. 
Consequently, as in the definition of rootedness, we have to respect the quantification order 
of the existential variables (like those from S' above) and perform their lookup in this order, 
substituting types as we go. As explained earlier, the definition of rootedness ensures that 
quantification order corresponds to dependency order. 

In fact, the lookup rules, in the case of multiple variables and of functors, also contain 
explicit side conditions that check that the returned type(s) do not contain the looked-up 
variable(s) themselves. The main reason for these side conditions is technical: building 
them into the lookup judgment removes mutual interdependencies between various prop- 
erties we prove below. In practice, they are implied by rootedness. 

Because the new definition of lookup is more complicated, its "simple" properties are a 
little bit less simple than before (cf. Lemma 5.4): 

Lemma 9.5 (Simple properties of type lookup with applicative functors) 

1. If lookup ff (E,E') t Tand anfv(E) =0,thenfv(f) C fv(E) Ufv(E') - a. 

2. If lookup ff (£,£') t t and head(» <£ fv(E), then fv(r) C fv(£) Ufv(£') -head(ff). 

3. Iflooku^E.EOtT andan(a'ufv(T')) = 0, 
then lookur%(£[f / /a'],£'[T / /a']) t t[t'/S / ]. 

4. If lookup^ (£,£') f T and fv(n) n (a' U fv(r')) = 0, 
then looku Pjt (E[T7a'],E'[T7a']) t T^/a']. 

(Moreover, in parts 3 and 4, the length of the derivation stays the same.) 

The soundness statement also requires a more verbose formulation than before, and 
because of the contravariant lookup in the functor case, both parts are mutually dependent: 

Theorem 9.6 (Soundness of type lookup with applicative functors) 
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1. Letrh£:i2andr,al-£':il If lookup* (£,£') t ?i> then T, a\-7t: K and Thn : K. 
Furthermore, if T h £ < £'[T2/a] for r h T2 : K a and 7T = a ocq (with a n ao = 0), 
then n = T2«o- 

2. Let T h £ : and r, a h £' : £1. If lookup^ (£, £') t Ti, then rh T\ : K a . 
Furthermore, if T h £ < 3a. H f T2, then Ti = T2. 

Proo/ - 

By simultaneous induction on the size of the derivation of the lookup. Interestingly, proving 
well-kindedness of the looked-up types requires slightly different inductive steps than 
proving the type equivalence(s). Part 1: 

• Case lookup* ([= Ti : k], [= x' : k]): Then % = x' . By inversion of well-kindedness, 
r h Ti : K and r, a h t' : K. Furthermore, by inversion of subtyping, Ti = t'[t2/(Z], 
for which we know via substitution that x'[X2/a] — n[X2/a] — ?2 «o- 

• Case lookup* ([= %" : T3], [= %' : T3]): Analogous. 

• Case lookup* ({I7£}, {F : £'}): Then lookup,, (£,£') t Ti for some £ e £ and £' e l! . 
By inverting well-kindedness, T h £ : i2 and r, a h £' : ii. The first claim then follows 
by induction. Furthermore, by inverting subtyping, T h £ < £' [T2 /a] , and the second 
claim likewise follows by induction. 

• Case lookup*(Vai .£1 — >-p £2,Vai.£j — £ 2 ): Then X\ = A(Xi.T3 such that both 
lookup S[ (£'j , £1 ) t t[ with a <£ fv{x[), and lookup*^ {L 2 [i'i/a\],l! 2 ) f T3. Let T\ = 
r,a,a[. First, inverting the landing rules, T,a\ h E1/E2 : ^ an d T'i l~ ^'1/^2 • 
For £1, we can weaken to T'^ai h £1 : Q, which allows us to invoke the induction 
hypothesis for part 2 and conclude T\ h tJ : )f C(1 . Because a ^ fv(r'i), the result can 
be strengthened to F, a\ h t{ : fc ai • 

Let r 2 = T, a\ . Obviously, T' 2 h [x[ /a 1 ] : T, a 1 , and applying the substitution lemma, 
T 2 h £2 [Ti /a 1 ] : £2. We can also use the substitution lemma to reorder F[ and derive 
T 2 , a h £ 2 : £2. We can now invoke the induction hypothesis on the codomains and 
get T 2 , a h ft a'j : re' and r' 2 h T3 : k'. With Lemma 9.1, we know both F 2 ,a\- n : 
a\ -> K"' and T h Act] .T3 : a'j -> Jf'. Given that the a[ are locally fresh by the usual 
variable convention, and thus don't occur in n, the former can be strengthened to 
r, a h % : a\ — > K"' as required. 

To furthermore prove the type equivalence, we can invert the subtyping assumption, 
revealing T' 2 h ^fo/a] < 3ai.£i t % and r ' 2 h e 2[t 2 /«i] < £ 2 [T 2 /a]. The sub- 
stitution lemma implies r' 2 h £j [T2/0S] : £2- And we can apply weakening to kinding 
of£i, such that r' 2 , ot\ h£i : Q. Using Lemma 9.5, lookup Si (£' t [x2/a],'L 1 [T2/01]) t 
fj^/a], but by variable containment we actually know that Li^/ce] = £1 and 
Tj^/ot] = x\. Because that modified lookup derivation is still shorter than the 
current one, we can invoke the induction hypothesis (part 2) for the type equivalence 
claim, and get x\ = x' 2 . As a consequence, £2pf 2 /ai] = E2p?'i/(Xi]- So we know 
about the codomain that r' 2 h Y.2[x[/ai] < £ 2 [T2/oc]. Consequently, the induction 
hypothesis (part 1) also implies T3 = aaoa\. or, via 77 -equivalence, Xa[.X3 — aao- 

Part 2: 

• Case lookupg (£,£'): There is nothing to show. 
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• Case lookup aa /(E,E'): Then fi = Ti,Tj and lookup a (E,E') f 1\ with fv(Ti) Ha' = 
0, and lookupj f /(E,E'[Ti/a]) t t',. By inverting well-kindedness, T, a,a' h L' : Q, 
which, via the substitution lemma, can be tweaked to T, a', a h E' : £2. At the same 
time, weakening gives r, a' h E : £2. Invoking the induction hypothesis (part 1) yields 
F,a',a\- a: K and F,a' h Ti : if. Inverting the former tells K= K a . And because the 
side condition says a' flfv(Ti) = 0, the latter can be strengthened to F h X\ : if a . We 
can invoke the substitution lemma to derive F, a' h E' [ti /a] : £2, which is enough to 
invoke the induction hypothesis again and conclude T h t( : K a i as well. 
Furthermore, for proving the type equivalence, inverting matching reveals T h E < 
E' [T2 , t' 2 /oi , a'] such that r h T2 : if« and rh^: K a > . And because T2 , T 2 are all well- 
formed in plain F, the variables a,a' don't appear free in them, so E'[t2,T 2 /(X, a'] = 
E'[T 2 /a'][T 2 /a] = E'[T 2 /a][T 2 /a']. Substitution on E' gives F,a h E'[T 2 /a'] : £2. 
By application of Lemma 9.5, we have lookup a (E[T 2 /a'],E'[T 2 /a']) t Ti[x' 2 /a']. 
By the variable convention, fv(E)fia' = 0. With the side condition on Ti, thus, 
lookup a (E, E' [t 2 /a'] ) t T i ■ Because that still has a derivation shorter than the current 
one, we can invoke the induction hypothesis (part 1) again on the first lookup, to 
obtain that Ti = T 2 . 

Consequently, lookup^E, E' [t 2 /oc] ) t Tj also holds (and still has a derivation smaller 
than the current one), and so does F,a' h E'[T 2 /a] : i2. Now, because E'[T 2 ,T 2 /a, a'] = 
E'[T 2 /a][T 2 /a'], we can apply U-MATCH to construct a derivation for F h E < 
3a'.E'[T 2 /o:] t ^'2- We can once more apply the induction hypothesis to that deriva- 
tion, which produces f[ = T 2 . □ 

Corollary 9.7 (Uniqueness of type lookup with applicative functors) 

Let T h E : and F h 3a.E' : i2 and T h E < 3a.E' t T. If lookup w (E,E') t Ti and 

lookup^(E,E') t T2, then Ti = T2 = T. 

Thanks to uniqueness, we can still read the lookup judgment as a quasi-deterministic 
algorithm. 

Let us now turn to completeness, which becomes significantly more involved as well: 

Theorem 9.8 (Completeness of type lookup with applicative functors) 
Let T h E : £2 valid and F h 3a. H : £2 explicit. 

1 . If T h E < E' [z/a] and F h x : K a , and 7T rooted in E' avoiding a, with % = a a \ and 
a ea andaflcti = 0, then lookup„.(E,E') t T a,\ with t = a[r/a]. 

2. If T h E < 3a .E' t T, then lookup^ (E, E') t T. 

Proof 

By simultaneous induction on the derivation of rootedness (implied by explicitness in part 
2). Part 1: 

• Case % rooted in [= t' : if]: Then % = t '. Inverting subtyping, we know E = [= x" : if] 
with x" = x'[x/a}. By substitution, n[x/a] = x'[x/a], and hence transitively, x" = 
n[x/a] = (a ai)[x/a] = xa\. So lookup^ ([= x" : k],[= x' : if]) t t ai. 

• Case n rooted in [= %' : x\: Analogous. 

• Case % rooted in {/' : E'}: Then % rooted in {/' : E'} ./ avoiding a. Inverting sub- 
typing, we know E = {ITE} and F h {TTL}.l < (P : ff}.l[z/a]. Inverting well- 
typedness and validity/explicitness, F \- {I : E}./ : Q. valid and F, a h {/' : E'}.Z : £2 
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explicit. Then by invoking the induction hypothesis, lookup^/ : £}./,{/' : E'}./) t 

T«i. 

• Case % rooted in Va'j.Ej — » P E' 2 : Then % a\ rooted in E 2 avoiding a and fv(Li) (~1 
a = 0. Let r' = r,Oi. Inverting subtyping, we know E = Vai.Ei — >- P E2 and P h 
Ej[f/a] < 3a - ! .Ei t ^\ and P h E 2 [Ti/a~i] < E 2 pf/a]. Moreover, inverting well- 
typedness and validity /explicitness gives F 7 a,a\ h E^/Ej : £2 explicit and, after 
weakening, T',ai h E1/E2 : £2 explicit/valid, where ai rooted in Ej. 

By substitution and Lemma 9.3, P h E' ; [t/S] : £2 valid. By typing rules and def- 
inition of explicitness, P h 3a 1 .Ei : £2 explicit. Consequently, we can invoke the 
induction hypothesis (part 2), and have lookup Si (Ej [f/a],Ei) f Ti. Because of the 
variable side condition on functor rootedness, E'Jr/a] =Ej. Moreover, because 
a £ fv(Ei) UE'j [f/a] by variable containment, Lemma 9.5 implies a ^ fv(Ti). That 
gives the first half of the definition of lookup in functors. 

Now, by soundness of type lookup, P h Ti : K ai ■ By substitution and Lemma 9.3, 
P h E2[ti/«i] : i2 valid. We invoke the induction hypothesis a second time (this 
time on part 1) and get lookup^ (E2[Ti/ai],E 2 ) |Ttti Ct\. Consequently, we can 
derive lookup ?t (E,E / ) f Aa'j .T ai a'j, and by 7] -equivalence, Aa'.Ti ai a' = Ti ai. 

Part 2: Inverting 3a. E' explicit implies a rooted in E'. 

• Case e rooted in E': Then there is nothing to show. 

• Case a, a' rooted in E': Then a rooted in E' avoiding a, a', and a' rooted in E'. 
Inverting matching implies T h E < E'[t, f' /a,a'} with T\- % : K a and r h %' : K a i. 
From inverting well-typedness and explicitness we get F, a ,a' h E' : £2 explicit. Let 
7T = a. Then we can invoke part 1 of the induction hypothesis to get lookup a (E, E') t 
T. By variable containment, fv(r) Da' = 0. 

By substitution and Lemma 9. 3, T, a' h E' [r/a] : £2 explicit and a' rooted in E' [r/a] , 
and so, T h 3a'.E'[r/a] : H explicit. Because r h % : K a and r h t' : ff a /, we know 
via variable containment that E'[t, x' /a,a'} = T.'[x/a][x' /a'}. With rule U-match 
we can then construct the derivation T h E < 3a' .11 [x/ a] t t'. With that, we can 
invoke part 2 of the induction hypothesis, to also get lookup^/ (E, E') f t'. □ 

As before, this property is sufficient to imply decidability of matching. (In addition, 
when we apply the matching rule U-MATCH algorithmically, we do not actually need to 
check the rule's side condition on the well-formedness of the types we have looked up, 
because it is already implied by soundness of lookup.) 

Corollary 9.9 {Decidability of matching with applicative functors) 

Assume that T is well-formed and valid, and also that T h X < x' / is decidable for 
types well-formed under F. If E valid and S explicit, and both are well-formed under F, 
then rhE<StT-^> / is still decidable in the presence of applicative functors and the 
relaxed definition of rootedness from Figure 41. 

Decidability of elaboration then follows as well, even though the elaboration rules under 
the applicative functor extensions are no longer purely syntactic: rules M-FUNCT-I and 
M-FUNCT-P overlap. However, they have disjoint premises, and thus the overlap does not 
induce any non-determinism. In the case of the multiple rules for value bindings, we have 
ensured the absence of overlap via syntactic side conditions. 
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Corollary 9.10 (Decidability of elaboration with applicative functors) 
Under valid and well-formed F, provided we can (simultaneously) show that core elabo- 
ration is decidable, then all judgments of module elaboration with applicative functors are 
decidable, too. 

Remark At this point, the alert reader may ask: Where did the alleged simplicity go? It is 
true that the above decidability proof is not as simple anymore. However, we like to make 
a couple of observations. 

First, the complexity witnessed above is only concerned with (signature matching for) 
applicative functors. The basic system from Sections 2-6, with generative functors only, 
is not affected. It is not completely surprising that applicative functors are more complex, 
considering the difficulties they have caused historically. 

Second, the declarative semantics of the system with applicative functors is only mildly 
more involved than that of the basic system. From our perspective, the rules are still 
fewer and smaller than in any of the previous accounts of applicative functors — especially 
considering that they also do more. Moreover, the soundness proof from Section 9. 1 is not 
substantially harder than the one for the basic system (Section 5.1) — and that arguably is 
all that is needed to understand the type system. 

What gets more complicated is the algorithm to implement type lookup (Section 9.2) — 
or rather, the proof that this algorithm (which, by itself, is only a few lines of code) 
is complete. However, this algorithm arguably is only relevant to implementors, and its 
correctness proof only interesting to experts. 

It is also worth noting that a fair amount of the encompassing complexity may actually 
be incidental. It is mainly due to the fact that our rules, unlike in most other systems, 
separate type lookup from subtyping. We chose this design because it makes the declarative 
subtyping rules pleasantly minimalist. For the basic system it also makes for an almost 
trivial lookup algorithm (Section 5.2). However, with the generalization to applicative 
functors, this factoring leads to a more complicated algorithm: in that system, lookup 
and subtyping become intertwined, which means that to separate them, lookup has to 
duplicate some of the work of subtyping, and its correctness proof needs to make sure that 
both algorithms operate in sync. The issue of rootedness could be avoided by decorating 
semantic signatures with "locators" (compare with Rossberg & Dreyer (2013)). A more 
traditional, interleaved, and algorithmic definition of matching would eliminate the need 
for a correctness proof altogether (while slightly complicating the declarative semantics 
and its soundness proof). We leave further exploration of this option to future work. 

Finally, it is also worth pointing out that our novel tracking of dynamic purity and 
dynamic module equivalence (Section 8) turns out to be only a minor extension to the 
system. In particular, it does not affect most of the definitions or proofs in a significant 
way — since value paths are modeled as phantom types, they are handled by the exact same 
mechanisms as ordinary abstract types. 



10 Mechanization in Coq 



One of our original motivations for the F-ing approach was that a simpler semantics for 
modules would be an easier starting point for language mechanization. As a proof of 
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concept, we embarked on mechanizing the elaboration semantics of Section 4 and Sec- 
tion 6 (but omitting normalization), and proved the soundness result of Theorem 5.1, but 
including module packages. 

We did so using Coq (Coq Development Team, 2007) and the locally nameless approach 
(LN) of Aydemir et al. (2008). (There is no reason we could not have used other proof 
assistants such as Twelf or Isabelle; but we were interested in learning Coq and testing the 
effectiveness of the locally nameless approach.) This effort required roughly 13,000 lines 
of Coq code. As inexpert users of Coq, we made little use of automation, so most likely, 
the proofs could easily be shortened significantly. 

As with any mechanization, there are some minor differences compared with the infor- 
mal system. Our mechanized F ro is simpler than the one we use here in that it supports just 
binary products, not records. Instead, we encode ordered records as derived forms using 
pairs, with derived typing rules, and target those during elaboration. Ordered records are 
easier to mechanize, yet adequate for elaboration. 

The F ffl mechanization does not allow rebindings of term variables in the context as our 
informal presentation does. Indeed, using the LN approach, subderivations arising from 
binding constructs have to hold for all locally fresh names. In the mechanization, we had 
to abandon the use of the injection from source identifiers to F,j, variables, and instead 
use a translation environment that twins source identifiers (which may be shadowed) with 
locally fresh F m variables (which may not). In this way, source identifiers are used to 
determine record labels, while their twinned variables are used to translate free occurrences 
of identifiers. Lee et al. (2007) use a similar trick in their Twelf mechanization of Standard 
ML. 

Our use of a non-injective record encoding means that different semantic signatures may 
be encoded by the same type. To avoid ambiguity, the mechanization therefore introduces a 
special syntactic class of semantic signatures (corresponding to the grammar in Figure 9), 
and separately defines the interpretation of semantic signatures as System F<b types by an 
inductive definition (again much like the syntactic sugar definitions in Figure 9). Conse- 
quently, the mechanized soundness theorems state that if C h M : S ~» e, then C° h e : S°, 
where _° denotes the interpretation of elaboration environments and semantic signatures 
into plain F ffl contexts and types. In retrospect, it would perhaps have been simpler to just 
beef up our target language with primitive records (as we have done on paper here). In any 
case, this issue is orthogonal to the rest of the mechanization effort. 

Our experience of applying the LN approach as advertised was more painful than we 
had anticipated. Compared to the sample LN developments, ours was different in making 
use of various forms of derived n-ary (as well as basic unary) binders and in dealing with 
a larger number of syntactic categories. Although we implemented the n-ary binders as 
derived forms over the unary ones provided by basic F ro , we still needed derived lemmas 
for n-ary substitution (substituting locally closed terms for free names) and n-ary open 
(for opening binders with locally closed terms). Then we needed lemmas relating the 
commutation of all the combinations of n-ary and unary operations. The final straw was 
dealing with rules (notably for sequencing of binding and declarations) that required us to 
extend the scope of bindings over terms from subderivations. Doing this the recommended 
way requires the introduction of a third family of closing operations (the inverse of open), 
for turning named variables back into bound indices, together with a plethora of lemmas 
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needed to actually reason about them (again with unary and n-versions of close and all 
possible commutations). We managed to work around these two cases by expressing the 
desired properties indirectly using additional (and thus unsatisfactory) premises stipulating 
equations between opened terms. 

In the end, out of a total of around 550 lemmas, approximately 400 were tedious "in- 
frastructure" lemmas; only the remainder had direct relevance to the meta-theory of F m or 
elaboration. The number of required infrastructure lemmas appears to be quadratic in the 
number of variable classes (type and value variables for us), the number of "substitution" 
operations needed per class (we got away with only using LN's subst and open, and 
avoiding close) and the arity classes (unary and n-ary) of binding constructs. So we 
cannot, hand-on-heart, recommend the vanilla LN style for anything but small, kernel 
language developments. It would, however, be interesting to see whether more recent 
proposals to streamline the LN approach (Aydemir et al, 2009) could significantly shorten 
larger developments like ours, without obscuring the presentation. 

Despite the tedium, the mechanization still turned out to be relatively straightforward 
overall, and did not require any technical ingenuity. We believe that a Coq user with more 
experience than us (or somebody with respective experience using another proof assistant) 
but without specialist background in modules, could easily have carried it out without much 
effort. 

11 Related work and discussion 

The literature on ML module semantics is voluminous and varied. We will therefore focus 
on the most closely related work. A more detailed history of various accounts of ML-style 
modules can be found in Chapter 2 of Russo's thesis (1998; 2003). 

Existential types for ADTs Mitchell & Plotkin (1988) were the first to connect the infor- 
mal notion of "abstract type" to the existential types of System F. In F, values of existential 
type are first-class, in the sense that the construction of an ADT may depend on run-time 
information. We exploit this observation in our elaboration of sealed structures, and more 
directly, in our support for modules as first-class values (Section 6), both of which are 
simply existential packages. 

Cardelli & Leroy (1990) explained how to interpret the dot notation, which arises nat- 
urally when defining ADTs as modules, via a program transformation into uses of exis- 
tentials. The idea is to unpack every existential immediately, such that the scope of the 
unpack matches the scope of the module definition. Our elaboration's use of unpacking 
and repacking can be viewed as a more compositional extension of this basic idea. 

Dependent type systems for modules In a very influential position paper, MacQueen 
(1986) criticized existential types as a basis for modular programming, arguing that the 
closed-scope elimination construct for existentials (unpack) is too weak and awkward to 
be usable in practice. MacQueen instead promoted the use of dependent function types 
and "strong sums" (i.e., dependently-typed record/tuple types) as a basis for modular 
programming. Since then, there has been a long line of work on understanding and evolving 
the ML module system in terms of increasingly more refined dependent type theories 
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(Harper & Mitchell, 1993; Harper et al, 1990; Harper & Lillibridge, 1994; Leroy, 1994; 
Leroy, 1996; Leroy, 1995; Shao, 1999; Dreyer et al, 2003; Dreyer, 2005). 

On the design side, the work on dependent type systems led to significant improvements 
in the expressiveness of ML modules, most notably the idea of translucency — i.e., the 
ability to include both abstract and transparent type declarations in signatures — which was 
independently proposed by Harper and Lillibridge (1994) and Leroy (1994). On the seman- 
tics side, however, the use of dependent type formalisms unleashed quite a can of worms. 
Several ideas and issues pop up again and again in the literature, and for the most part the 
"F-ing modules" approach either renders these issues moot or offers straightforward ways 
of handling them. 

One recurrent notion is phase separation, which is essentially the observation that the 
"dependent" types in these module systems are not really dependent. The signature of a 
module may depend on the type components of another module, but not on its value com- 
ponents. Thus, as Harper, Mitchell & Moggi (1990) showed (for an early ML-style module 
system without translucency or sealing), one can "phase-split" a (higher-order) module into 
an F<n type (representing its type components) and an ¥ m expression (representing its value 
components). Our approach of interpreting ML modules into F ffl is of course completely 
compatible with the idea of phase separation, since we don't pretend our type system is 
dependent in the first place. 

Another recurrent notion is projectibility — that is, from which module expressions can 
one project out the type and value components? As Dreyer, Crary & Harper (2003) ob- 
served, the differences between several different dialects of the ML module system can 
be characterized by how they define projectibility. Most dependent module type systems 
define projectibility by only allowing projections from modules from a certain restricted 
syntactic class of paths. We also employ paths, but define them semantically to be any mod- 
ule expressions whose signatures do not mention any "local" (i.e., existentially-quantified) 
abstract types. We consider this criterion to be simpler to understand and less ad hoc. 
Russo (1998) describes and formalizes a similar notion of "generalized path", with an 
analogous type-based restriction, as part of his system of higher-order functors. But the 
motivation is solely the ability to express paths like (FM).t, whereas for F-ing modules, 
we harvest their expressive power as a way of simplifying the language and its rules. 

A common stumbling block in dependent module type systems is the so-called avoid- 
ance problem. Originally observed in the setting of (a bounded existential extension of) 
System F< by Ghelli & Pierce (1998), the avoidance problem is roughly that a module 
might not have a principal signature (i.e., minimal in the subtyping hierarchy) that "avoids" 
(i.e., does not depend on) some local abstract type. As principal signatures are important 
for practical typechecking, dependent module type systems typically either lack complete 
typechecking algorithms (e.g., Lillibridge (1997) and Leroy (2000)) or else require (at least 
in some cases) extra signature annotations when leaving the scope of an abstract type (e.g., 
Shao (1999), Dreyer et al. (2003)). In contrast, under our approach the avoidance problem 
does not arise at all: the semantic signature 3a.E of a module M keeps track of all the 
abstract types a defined by M, even those which have "gone out of scope" in the sense that 
they are not "rooted" anywhere in E (to use the terminology of Section 5). Thus, the only 
point at which we need to "avoid" anything is when we typecheck a path; at that point, we 
need to make sure that its signature does not depend on any local abstract types. Of course, 
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at that point the avoidance check is not a "problem" but rather the crucial defining element 
of well-formedness for paths. 

Elaboration semantics for modules Our avoidance of the avoidance problem is due 
primarily to our use of an elaboration semantics, which gives us the flexibility to classify a 
module using a semantic signature S that is not the translation of any syntactic signature S 
(i.e., it is valid, but not explicit, as defined in Section 5.2). Harper & Stone (2000) exploit 
elaboration in a similar fashion and to similar ends. One downside of this approach, some 
(e.g., Shao (1999)) would argue, is that one loses "fully syntactic" signatures — i.e., the 
ability to express the full static information about any module using a syntactic signature, 
and thus typecheck the module independently from the context in which it is used. But 
it is not clear that in practice this is really such a big deal, because a programmer can 
always avoid "non-syntactic" signatures by either adding a binding or an explicit signature 
annotation. In fact, Shao's approach to ruling out non-syntactic signatures would simply 
amount to restricting the projection rule M-DOT (Figure 14) in the same way as the path 
rule P-MOD (Figure 17) in our system, thereby forcing the programmer to take these 
measures. 

Perhaps a more serious concern is: how does the elaboration semantics we have given 
here correspond to existing specifications of ML modules, such as the Definition of SML 
or Harper-Stone? In what sense are we formalizing the semantics of "ML modules"? 

The short answer is that it is very difficult to prove a precise correspondence between 
different accounts of the ML module system. In the few cases where such proofs have 
been attempted, the formalizations in question were either not representative of the full 
ML module system (e.g., Leroy (1996)) or were lacking some key component, such as a 
dynamic semantics (e.g., Russo (1998)). Moreover, one of the main advantages of our ap- 
proach (we believe) is that it is simpler than previous approaches. We are not so interested 
in "correctness", i.e., whether our semantics precisely matches that of Standard ML, the 
archaeological artifact; rather, we wish to suggest a way forward in the understanding and 
evolution of ML-style module systems. That said, we believe (based on experience) that 
our semantics for modules in Section 4 is essentially a conservative extension of SML's, as 
well as the generative fragment of Moscow ML (Russo, 2003). 

Higher-order modules and applicative functors The main way in which the language 
defined in Section 4 diverges from Standard ML is its support for higher-order modules, 
which constitute a relatively simple extension if one sticks to the generative semantics 
for functors. (Our semantics for higher-order modules in that section is similar to that of 
Leroy (1994; 1996) and Harper & Lillibridge (1994).) However, as a number of researchers 
noted in the early years of ML modules, the generative semantics is also fairly restrictive, 
because it assumes conservatively that any types specified abstractly in the result signature 
of an unknown functor will be generated anew every time the functor is applied. For 
example, if a higher-order functor H has a functor argument F of type S — > S, then H 
must account for the possibility that F is instantiated with an impure/generative functor 
and treat it as such during the typechecking of Z/'s body, even though H may in fact 
be instantiated with a transparent F like the identity functor. Thus, under a generative 
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semantics, abstraction over functor arguments can result in the rejection of seemingly 
reasonable programs due to insufficient propagation of type information. 

Harper, Mitchell & Moggi (1990) were the first to propose the use of an applicative 
semantics (although they did not call it that) for achieving more flexible typechecking of 
higher-order functors. Leroy (1995) later popularized the idea of applicative functor se- 
mantics in the setting of a more fully realized module language, and it is his semantics that 
serves as the basis of OCaml's module system. In addition to better supporting higher-order 
modules, Leroy also motivated applicative semantics by the desire to treat semantically 
equivalent types {e.g., integer sets) as equivalent, even if they were created by separate 
(but equal) instantiations of the same functor. Indeed, this latter motivation has in practice 
turned out to be arguably more compelling than the one concerning higher-order modules. 

As we pointed out at the beginning of Section 8, the applicative functor semantics 
does not obviate generative semantics — both are appropriate in different instances — but 
constructing a language that supports and reconciles both forms has proven very difficult. 
Several proposals have been made (Shao, 1999; Russo, 2003; Dreyer et ai, 2003), but all 
of them suffer from breaking abstraction safety (cf. Section 8 for examples). 

Our semantics of applicative functors in Sections 7 and 8 is novel and does not corre- 
spond directly to any existing account. As we explained in those sections, our motivation 
has been to provide an account of applicative functors that is (a) simple, (b) abstraction- 
safe, and (c) not overly conservative. To achieve simplicity, we adopt the adage that "ap- 
plicative = pure" and "generative = impure". To achieve abstraction safety, we employ 
"stamps" (modeled as hidden abstract types) to statically track the identity of values, so 
that, for instance, the identity of the type of sets can depend (as it should) on the identity 
of the comparison function by which its elements are ordered. While this approach is 
necessarily conservative (in order to ensure decidability of typechecking), it is no more 
conservative than other abstraction-safe designs, and we have tried to be as liberal as 
possible by tracking identity at the level of individual value components. 

Technically, our semantics for applicative functors is based closely on the formulation 
in Russo's thesis (Russo, 1998). Although we believe the applicative higher-order modules 
of (Russo, 1998) to be sound, their subsequent integration with Standard ML modules in 
Moscow ML turned out not to be (Dreyer et ai, 2002). In an attempt at backward com- 
patibility, Moscow MLs early releases supported both applicative and generative higher- 
order functors. The typing relation was a seductively straightforward integration of both the 
generative and applicative rules. Dreyer's counterexample to type soundness is recounted 
by Russo (2003), together with a relatively simple, if unproven, fix. Even if a revised 
Moscow ML can be proven type sound, we claim that the marriage of applicative and 
generative functors presented in this article remains superior, by offering abstraction safety 
over and above simple type safety. In our refined system, only those abstract types whose 
invariants are guaranteed not to be tied to mutable state are rendered applicative. Moscow 
ML provides no such guarantee and freely allows the coercion of a generative into an 
applicative functor (by simple 77 -expansion). 

We credit Biswas (1995) with discovering the skolemization technique for typing ap- 
plicative higher-order functors: he used it to introduce higher-kinded universal quantifiers, 
parameterizing a higher-order functor on its argument's type dependencies in order to prop- 
agate actual dependencies at application of the functor (by implicit type application). The 
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contribution of Russo (1998) was to additionally use higher-kinded existential quantifiers 
to abstract (and thus hide) concrete type dependencies at module sealing (by an implicit 
pack). Shao (1999) uses a similar skolemization technique, with the difference being that he 
collects all abstract types of a given module into a single variable of higher-order product 
kind (the module's "flexroot"), instead of quantifying them separately in a sequence of indi- 
vidual variables. Unfortunately, employing this "uncurried" formulation would necessitate 
jumping through extra hoops to handle the avoidance problem or constructs like where 
(besides relying on a mild extension to F ffl 's type language). 

We point out that the addition of applicative signatures alone {i.e., the basic system 
from Section 4, extended with only the rules from Figure 26, but without the refined 
module elaboration from Figure 29) subsumes the more limited applicative functors of 
Shao (1999). Shao's system, like ours, distinguishes between opaque and transparent func- 
tor signatures, with the latter using higher-order type constructors to abstract over static 
type dependencies. The difference is that in Shao's system, the only way to introduce an 
applicative functor is to seal a fully transparent functor by an applicative functor signature. 
This simple design choice has as an unfortunate side-effect: in Shao's system, unlike ours, a 
user cannot use sealing within the body of an applicative functor. The ability to use sealing 
inside an applicative functor is a desirable feature, since in principle one may wish to 
impose abstraction boundaries at any point inside a module, and indeed it is supported by 
most other designs, including our own. Furthermore, we depend crucially on this feature in 
our semantics of value sharing (via phantom types), which we depend on in turn to ensure 
abstraction safety. Specifically, we treat every value binding in a module as if it were a 
little sealed submodule, introducing an abstract phantom type to statically represent the 
identity of the value. In a system like Shao's, such an approach would automatically cause 
any functor (with a value component in it) to be treated as generative. Consequently, we do 
not know how to effectively enforce abstraction safety in a system like Shao's. 

The module calculus of Dreyer, Crary & Harper (2003) provides support for both the 
"strong" Shao-style sealing construct, which demands generativity of (immediately) en- 
closing functors, and a "weak" variant of sealing, which does not demand generativity and 
may thus be used inside applicative functors. Dreyer et al. account for these two variants 
in terms of a dichotomy between "dynamic effects" and "static effects". In our system, 
we have only retained the weak variant of sealing (adjusted to properly ensure abstraction 
safety), because our point of view is that the need for generativity has solely to do with 
the computational effects in the module being sealed, and that sealing per se is not a 
computational effect. Of course, if one really wished to "strongly seal" a pure module 
in our language, one could easily do so by inserting an impure no-op expression into the 
body of the module, thus inducing a pro forma effect. But we see no compelling reason for 
wanting to strongly seal a pure module. 

An alternative semantics for higher-order functors was proposed by MacQueen & Tofte 
(1994), but it relied fundamentally on the idea of re-elaborating a functor's body at each 
application. In recent work, Kuan & MacQueen (2009) have investigated how to account 
for such a semantics in a more satisfactory way by tracking the "static effects" of higher- 
order functors in an "entity calculus". However, it remains unclear how to reconcile their 
approach, which underlies the module system of modern-day SML/NJ, with the tradition 
of type-theoretic accounts of ML modules to which "F-ing modules" belongs. 
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Interpreting ML modules into F a We are certainly not the first to explain ML mod- 
ules by translation into F a . Harper, Mitchell & Moggi (1990) give a "phase-splitting" 
translation of an early ML module calculus into an F ffl -like language, but do not yet deal 
with the crucial aspect of type generativity. As mentioned above, Cardelli & Leroy (1990) 
show how a calculus with dot notation — i.e., with a mildly dependently-typed variant of 
System F existentials whose witness type is projectible on the type level — can be translated 
down to plain System F existentials. Shao (1999) gives a multi-stage translation of his more 
advanced module calculus into a language called FTC, which is a variant of F ffl enriched 
with Cardelli/Leroy-style dot notation and a restricted form of dependent products for 
expressing functors. However, he does not provide any translation of this language into 
F ffl itself, and it is not obvious how to extend the Cardelli/Leroy translation to FTC. 

Shan (2004) presents a type-directed translation of the Dreyer-Crary-Harper module cal- 
culus (Dreyer et ai, 2003) into F^. His translation naturally uses some techniques similar 
to ours. In particular, his translation of signatures closely mirrors that of Russo (1998; 
1999; 2003), and to translate module terms, he opens and repacks existentials in the same 
way we do. Our elaboration also borrows from Shan the technique of abstracting over the 
whole environment for the translation of applicative functors. 

The biggest difference between these previous translations and ours is that the previous 
ones all start from a pre-existing dependently-typed module language and show how to 
translate it down to F m . This translation is directed by (and impossible without) the types 
and contexts from the source language. We instead use the type structure of F ra in order to 
give a static semantics for ML modules directly. Thus, we feel our approach is simpler and 
more accessible to someone who already understands F ffl and does not want to learn a new 
dependent type system just in order to understand the semantics of ML modules. 

As explained in the introduction, our approach can be viewed as giving an evidence 
translation, and thus a soundness proof, for (a variant of) the static semantics of SML 
modules given in Russo's thesis (Russo, 1998; Russo, 1999). Russo started with the Defi- 
nition of Standard ML (Milner et ai, 1997), and observed that its ad hoc "semantic object" 
language could be understood quite clearly in terms of universal and existential types. 
A key observation, also made by Elsman (1999), was that the state of generated type 
variables, threaded as it was through the static semantics of SML, could be presented more 
declaratively as the systematic introduction and elimination of existential types. Given the 
non-dependent, F ra -like structure of the semantic objects, it was also relatively straightfor- 
ward to extend them to higher-order and first-class modules (Russo, 1998; Russo, 2000). 

We point the interested reader to Chapter 9 of Russo's thesis (1998; 2003) for an in-depth 
comparison with the non-dependent approach to modules that he pioneered (and that the 
F-ing approach is derived from), giving targeted examples to pinpoint the problems with 
dependently typed accounts and how they are avoided by this approach. 

It is worth noting that our approach also scales to handle more ambitious module- 
language extensions, at least if one is willing to beef up the target language somewhat. In- 
spired by Russo's work, Dreyer proposed an extension of Fo called RTG (Dreyer, 2007a), 
which he and coauthors later used as the target of an elaboration semantics for recursive 
modules (Dreyer, 2007b), mixin modules (Rossberg & Dreyer, 2013), and modules in 
the presence of type inference (Dreyer & Blume, 2007). These elaboration semantics are 
similar to ours in that they use the type structure of the (beefed-up) F ffl language in order 
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to directly encode semantic signatures for ML-style modules. However, our semantics is 
significantly simpler, since we are only trying to formalize a non-recursive ML-like module 
system and we are only using plain F ra as the target language. 

Mechanization of module semantics Lee et al. (2007) mechanized the meta-theory of 
full Standard ML, based on a variant of Harper-Stone elaboration given by Dreyer in 
his thesis (Dreyer, 2005). It is difficult to compare the mechanizations, since theirs uses 
Twelf. However, it is worth noting that a significant piece of their mechanization is devoted 
to proving meta-theoretic properties of their target language, which employs singleton 
kinds (Stone & Harper, 2006). In contrast, since our internal language is so simple and 
well-studied, we largely took it for granted (though we have proved the F ffl properties that 
we use). 

Direct modular programming in F ro Lastly, several authors have advocated doing mod- 
ular programming directly in a rich F ffl -like core language like Haskell's (Jones, 1996; 
Shields & Peyton Jones, 2002; Shan, 2004), using universal types for client-side data 
abstraction and existential types for implementor-side data abstraction. Several other au- 
thors (MacQueen, 1986; Harper & Pierce, 2005) have argued why this approach is not 
practical. The common theme of the arguments is that ¥ m is too low-level a language to 
program modules in directly, and that ML modules provide a much higher-level idiom for 
modular programming. More recently, Montagu & Remy (2009) have proposed directly 
programming in a variant of Dreyer's RTG (Dreyer, 2007a) (see above), because RTG 
addresses to some extent the limitations of closed-scope existential elimination. However, 
RTG is still quite low-level compared to ML modules. 

In some sense, the point of the present article is to observe that the high-level elegance 
of ML modules and the simplicity of F ra typing are not mutually exclusive. One can 
understand ML modules precisely as a stylized idiom — a design pattern, if you will — 
for constructing F m programs. The key benefit of programming this idiom using the ML 
module system, instead of directly in F ra , is that elaboration offers a significant degree 
of automation (e.g., by inferring signature coercions and implicitly unpacking/repacking 
existentials), which in practice is extremely useful. 

12 Conclusion 

In this article, we have shown that it is possible to give a direct, type -theoretic semantics for 
a comprehensive ML-style module system by elaboration into standard System Fa,. In so 
doing, we have also offered a novel account of applicative vs. generative functor semantics 
(via a simple "pure/impure" distinction), which avoids the problems with abstraction safety 
that have plagued previous accounts. 

Our main focus has been on semantics — a concern that we have not addressed in this 
article is implementation. As already alluded to in several places (such as Section 4 and 
Section 7.3), we do not expect a real-world compiler to implement the F-ing rules verbatim. 
Obvious optimizations include: eliminating redundant administrative redexes at compile 
time, introducing type tuples to group semantic type parameters into single variables (ef- 
fectively reconstructing structure stamps), lazily expanding type abbreviations, and mini- 
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mizing the environments abstracted over by applicative functors. It also seems preferable 
for compilers to reconstruct user-friendly syntactic type expressions where possible when 
presenting semantic types to users. Most of these techniques are well known, and we do 
not envision any particular difficulties in applying them to our system. But such concerns 
are outside the scope of this article. 

Finally, while our semantics of ML modules accounts for almost all of the major features 
that can be found either in the literature or in the various implemented dialects of ML, there 
is one key feature we have left out: recursive modules. As Dreyer (2007a) has observed, the 
combination of recursion and ML-style abstract data types seems to demand an underlying 
type theory that goes beyond plain System F ro , and moreover, in our opinion, doing re- 
cursive modules "right" requires abandoning some of the fundamental design decisions of 
traditional ML modules. Nevertheless, the basic ideas of the "F-ing" approach still apply: 
a semantics for recursive modules can be given using a variation of our elaboration, and 
targeting a language that is a conservative extension of F m . The first and last authors' work 
on MixML, a module system with recursive mixin composition, explores precisely that 
path (Rossberg & Dreyer, 2013). 
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